The Intrinsic Value Of Shortening The Software Release Cycle

10 things that release cycles define about your company.

How many weeks does it take to complete one cycle? What is the impact of that?

Companies can opt-in different layers before code makes it to production and becomes available to customers. After development, the act of writing code, companies can use code-review, a senior developer reviewing the code, Quality Assurance, QA consists of manual testing, User Acceptance Testing, UAT is product managers reviewing the feature, Canary Deploys, deploying code to a subset of users…etc.

The process by which a company releases code defines the kind of company it is. An engineering driven company like Facebook has a very short release cycle to drive innovation. A transaction driven company like a bank has a much slower cycle to ensure quality. It’s not an art to define what’s best for you, it’s just numbers. Do you often meet deadlines? Do you need to innovate fast? Does your system go down for hours before getting fixed?

Shortening the cycle

Most tech companies of the 20th century worked very hard in shortening the cycle. Companies like Tumblr, Github, Facebook all removed the need for QA. A short cycle will mean that:

1. Engineering gets better. When there is no barriers/filters/gateways to production, engineers will better themselves. It’s just like Batman, The Dark Knight Rises where Christian Bale makes it out of the pit. By removing the safety rope, he suddenly jumped a little higher. On a more serious note, remember that a bug found in QA, or UAT, means moving back to development in the cycle, and that takes time.
2. Infrastructure gets more resilient. It’s not sustainable to deploy code without a resilient infrastructure, and your engineers will have to fix that. For instance, you should always be able to rollback to a previous working version of your software. Canary deploys — deploying to a very small subset of users and monitoring before deploying to all users — can minimize the impact of bad code in production.
3. Your software is more tested. Tests automation becomes part of the culture. Tests will help catch regression bugs, which could be the bar by which you decide to release code. “If it doesn’t break the current code, deploy it!”. You can read more about automating tests here, a great article by Sarah Fittje.
4. With increased engineering productivity comes an innovating culture. When deploying is part of the culture, engineers are more dynamic, resilient to failures themselves, less driven by theories, and more ready to experiment right in production. You are enabling your talent pool to show you what’s next.
5. Deploys become safe. Any engineer should be able to deploy, and those deploys will become smaller over time. The more barriers to productions the bigger the release will be. When you are not deploying, engineers are still writing code — the snowball gets bigger, and havoc reigns at the sight of it.
6. You will quickly pinpoint who can survive this chaotic environment. Some engineer won’t like chaos, others will thrive. It takes a lot of courage, and smarts, and teamwork to work in a company which releases code daily. For example, Facebook is running multiple versions of its social network platform in production — in fact over ten thousand versions— which enables them to constantly gather data about its new features. Engineers will need to take the risk to be running one of those versions.
7. You will save money, so you can hire more engineers. If your environment is adequatly stable, then you can reproduce your company model. Hire more engineers, deploy more, and repeat. It scales. If you add more people to your release cycle, then…
8. Client deadlines are more approachable. If you have demanding clients, breaking the projects into smaller tasks and releasing them will become easier. Your clients will be able to test before the full set of features is complete. In the case where you are late, you may decide to trim some of your tasks.
9. The overhead of having stale code is close to non-existent. Code that sit stills costs money. If it needs to make it to production, it needs to be brought back to life with the current production code. If it needs to be removed, then it should have never been built in the first place.
10. Happier engineers. After all the goal is to make it to production. If half the engineers’ blood and sweat goes to waste, moral will be down!

If you wonder about what the development team does, the best place for business development, product managers, sales is to ask questions about the release cycle. Sometimes, it takes an outsider to understand what makes sense for the development team. And it can change everything about a company. Invest in your cycles!

Current read: Zero To One By Peter Thiel