If It’s Not on Prod, It Doesn’t Count: The Value of Frequent Releases

  09 Apr 2012

At Shutterstock, we like to release code. A lot. We do it about 60 times per week.

Frequent code releases have become somewhat of a mantra among today’s fast-moving startups, but the value they bring isn’t always articulated well. In fact, there are a lot of reasons not to push frequently: you could release shoddy or incomplete software, it might not be thoroughly tested, or you might not like the constant pressure of production deployments.

So it’s worth stepping back to look at all the benefits that frequent releases bring:

1) You deliver value to customers more quickly.

This is the first principle of the agile manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Features that are sitting in your development environment aren’t benefiting your customers. Frequent releases get those features into the wild so that your customers can use them.

Be sure to relentlessly focus on delivering value to customers. Too often, frequent releases are interpreted as breaking big, complicated projects into component parts: first you tackle database schema changes, then business logic, then graphic design. That’s not the point. The point is to deliver complete, valuable features to customers as quickly as possible.

This idea also isn’t about releasing half-baked or hacky code. The art is in finding the smallest implementation the team can develop, test, and release within a short period of time. It helps to ask yourself, “what is the smallest impactful change we can make to get to our goal?” Then, challenge what you decided was “smallest” — can you really not get there with an even smaller implementation? In the end, you want to do the minimal work to test your idea with customers, then learn and repeat.

2) You learn quickly.

The lean software movement has popularized a revolutionary business philosophy: We don’t know what the best thing to do is. The only way we can know it is to put something in front of customers and get their reactions to it.

By releasing software frequently, you have many more opportunities to get customer feedback and pivot based on it. You avoid going too far down a path that’s not valuable.

3) It forces you to break big ideas into manageable pieces.

Big projects are risky, complex, and interminable. By breaking big projects into small pieces and releasing one piece at a time, we not only deliver value more quickly, but we avoid death marches that demoralize software teams.

This is far easier said than done, because everyone loves big, splashy projects — they generate attention, they get people excited, and they offer a fleeting sense of accomplishment. But users rarely like big, splashy projects. In fact, users generally don’t like any sort of change; it forces them to re-learn something that they don’t want to re-learn. By delivering small pieces of functionality, you provide additional value to users without surprising them with radical change.

Some people will object that an incremental process ultimately takes longer than a monolithic one. That’s okay — it’s a trade-off we’re very happy to make, for two reasons: first, although the final result may end up in customers’ hands later, we’ve been delivering small pieces of value the whole time. Second, it lets us change direction along the way as we learn instead of committing to a big project that we’re not sure has value.

4) You avoid horrible merges.

Merging code has always been and always will be a pain in the ass. The more we can avoid it, the happier and more productive we’ll all be. Frequent releases mean that code merges are small and simple (if they’re necessary at all). This means you can move more quickly, and developers stay happier.

5) With good automated testing and an a/b testing platform, you reduce risk.

One complication of releasing frequently is making sure that your software works well and is thoroughly tested. That’s why automated tests are so important in an agile environment — they let you quickly and thoroughly ensure that your code works. Shorter release cycles inherently produce smaller code pushes. In general, smaller code pushes are less risky simply because fewer things can go wrong. By coupling small code pushes with automated testing, you can move quickly with little risk.

A good a/b testing platform also lets you iterate rapidly with low risk. If you’re able to test changes on 1% of your customers, you drastically reduce the risk associated with rolling out new features, and are able to learn and adapt more quickly.

6) You reduce complexity.

Lots of developers like to over-engineer. Given enough time, we’ll build dozens of layers of unnecessary abstraction (see Parkison’s Law). By requiring frequent releases, we push ourselves to choose the simplest path forward.

If not done well, it is possible to paint yourself into a corner with this approach. It’s important to remember that frequent releases don’t mean short-sighted thinking. You can still get to a distant goal by approaching it one step at a time.

7) It keeps people motivated.

Who wants to work on a project for months (or years) and never have the thrill of showing it off to their friends? Or hearing what customers think of it? Frequent releases motivate people by letting them see the results of their hard work.

We use the scrum/agile framework, with two-week sprints and a demo at the end of each iteration. A few years ago we started enforcing a rule to drive this point home: you can only demo what’s on production. If it’s not on prod, it doesn’t count. That’s our way of saying, “You can code all you want, but all that matters is what our customers can do with it.”

For all these reasons, we evangelize frequent releases. That’s not meant to minimize their difficulty. It’s often very challenging to figure out how to take a small step forward that delivers value to customers while working towards a more distant goal and letting you change direction if necessary. We never said it was easy. In fact, it’s probably one of the most difficult problems in modern software development, because it requires developers to not only be great architects but also appreciate customer needs and product development. But it’s the best method we’ve found for moving our business forward quickly while minimizing risk.

comments powered by Disqus