Lessons Learned From Shipping a Large Project
These are the lessons I've learned from shipping a year-long software project.
Today at work we shipped a large project that I had been working on for over a year. Not only did I have to create a new feature from the ground up, but that feature was WebVR, so I had to figure out how the interface was going to work, how to integrate it with our current product, and solve cross-browser issues with the ever-changing WebVR specification.
These are a few things I've learned working on this project for the past year:
- Patience is a virtue with new technologies. I was able to implement features in the last six months that wouldn't have been possible in the first half of 2017. Slowing down the pace of development and taking deliberate pauses to work on other projects allowed for the WebVR spec to catch up to our product wishlist.
- Taking a break to work on something else can be a great way to recharge your batteries, just be sure your code is well-commented or self-documenting, otherwise you're going to have a bad time when you resume work on the main project.
- Be sure the code works after it's compiled. Heck, make sure it's going to compile in the first place! Sometimes adding new libraries to an existing codebase can wreak havoc with the delicate ecosystem.
- After living with your code for so long, your perspective is going to get weird. Ask people of a variety of backgrounds to take your product for a test drive, if possible. Get a bunch of honest opinions and suggestions. Make changes as needed.
- Don't spend too much time in VR. It will wear your eyes out faster than looking at a regular computer monitor. Take regular breaks from both VR and the computer screen. Take care of your peepers.
- Iterate interface designs on paper/whiteboard before putting any code to IDE. Then be prepared to code half of it before throwing all those formerly great ideas in the trash.
- Like a great writer, be ready to kill your darlings. You're going to make something really cool and changes will have to be made for a variety of reasons. Don't get sassy with it, just do it and make it even better than the original.
- Try to keep notes. It's hard to stay organized when you're trying to add features but it'll be a lifesaver in ten months when you're asked about how a feature works.
- Get weird with it. Before even sending it off to QA, try to make the craziest use cases you can think of. It'll save everyone some time if you do some of your own testing.
- Something will break in production and if that doesn't happen on its own, don't worry, someone will come along shortly and break everything. I'm waiting for someone to try to upload a 64x64 animated gif as a VR background.