My previous jobs had what I consider a fairly standard month long release cycle. The first three weeks of the were spend writing code. On the fourth week the code was dropped to QA where they would hammer on it, find bugs, and have developers fix them. At the end of the fourth week the code shipped.
I distinctly recall the final week before every release having an uneasy feeling in my stomach. Even though I had thoroughly tested my code and QA had signed off on it, I always worried that it would break horribly in production. Did I miss a corner-case? Was someone integrating with my code going to break it? Had there been regressions in the mad rush to get fixes in before the release? I’ll never forget that feeling....
That is why I was really surprised when I started working at turntable.fm. I distinctly recall when I finished my first (tiny) feature. After quadruple-checking the code to make sure all the digital i’s were dotted and t’s crossed I sent it off to code review. Another developer took a look and said “Yep, looks good.” I naively asked, “when is the next release?” To which he responded “Right now.” Uh oh, I was getting that feeling again... but just a minute later the code had been deployed and there was my shiny new feature staring me in the face, working just as I had hoped. It was a special moment.
This had a profound effect on how I think about deploying code. I often get asked what is our release process, to which I reply “we ship when the code is ready.” It’s just that simple.
I’ve observed many benefits of this release strategy:- Instant gratification. There is nothing like the constant positive reinforcement of frequently shipping shiny new features. As a developer this kicks my motivation into overdrive.
- You’re users get a constant stream of new features rather than having to wait for what amounts to a “monthly feature dump.” After you push new features and ask your users if they can spot them, you’ll be surprised at how quick they identify them.
- When each feature is pushed separately it is a lot easier to gauge your users response. Just like with A/B testing, to get a clear response you want to minimize all other factors.
- All the integration and testing is done by the developer shipping the feature. This means if anything goes wrong its obvious who should be investigating the issue.
- If there are problems it is easy to roll-back since your change is that only thing that got pushed.
- Debugging any issues with the code is easier since the code is still fresh in your mind. Getting all of the code you wrote a week (or a month) ago back in your brain can take longer then you would expect.
