“Release Early, Release Often” Clarified, Part 1.

This article is one of the “IT Terminology Clarified” series.

This is an abridged version of the original article on my Medium blog, 2022-10-20.

Most IT professionals have heard IT executives talking about “Release Early; Release Often” a lot, typically in company town hall meetings. However, this phrase has become an ideal slogan, which is meaningless in everyday life.

Most CIOs like the idea of “Release Early; Release Often”, but they have never experienced it. At the bottom of their hearts, they are not even sure if they really want it. This Chinese idiom describes this kind of behavior very well. Without the strong determination of the CEO/CIO, the middle tier: senior VPs, managers, fake agile coaches, fake scrum masters, fake DevOps leads, and architects, would just do some fake work under the banner of “Release Early, Release Often”. For most of those people, this is just a job, and fearing change is normal.

If you are a CIO/CEO and really want to achieve “Release Early; Release Often” and would like a real-life case study at a large IT organization. I recommend Wired’s article: The Software Revolution Behind LinkedIn’s Gushing Profits.

I will share my thoughts on this slogan in this article.

A Story

I worked as a test automation consultant at a large tech company about a decade ago. At a company town hall meeting, the CEO and CIO spoke passionately about the ‘Agile Transformation’ the company was currently doing. Inevitably, both of them mentioned “Release Early; Release Often” a few times.

The company invited a guest speaker who was the CEO of an Agile Consulting company (the headquarter in Melbourne). He was a passionate speaker, in Steve Ballmer’s style.

Instead of talking about “Developers”, this CEO repeatedly said, “Automation, Automation, Automation” and “Testing, Testing, Testing” (please note that this was a cunning trick, and explanations will be followed later). Towards the end of his speech, he told us a story: recently, his consultants helped an organization achieve 45 production releases a day”. The audience applauded, including my project manager Mark. As Mark was sitting next to me, I whispered to him: “It must be a lie!”. Mark looked at me surprisedly, “Why? ”(by the way, Mark has worked with me on two projects, both of which achieved production deployment every sprint thanks to the daily automated regression testing I implemented)

I replied: “A simple math. 45 production releases per eight hours, that is, ~10 minutes per release. How long will the regression testing take? What are the reasons for a release? If his company could do good automated regression testing, surely he would talk about it a lot and show stats. But he didn’t. What is the value of deploying again and again without code changes? ”

Mark understood instantly and agreed with me. Like many other people, he was influenced by the atmosphere and forgot about logical thinking.

I continued: “If 10 minutes is pure deployment time, it will be meaningless. The typical deployment time for all my web apps is about 20 seconds. If we follow his logic, we will do thousands of production deployments per day, but for what? The main cost of a production release cycle is automated regression testing (via UI)! He did not mention end-to-end test automation at all but only said the words ‘testing’ and ‘automation’ repeatedly and separately. That’s cunning”.

After the town hall meeting, this agile consulting company was engaged to help improve the agile process of the company’s flagship product, i.e. to make it ‘Release Early; Release Often”. There was no more news after that. To my knowledge, no changes had been implemented (the teams, with the exception of mine, were still doing manual testing) by the time I left the company.

A few months later, I had a LinkedIn chat with a former colleague who was working at a large bank in Melbourne. I learned from him that the agile consulting company’s CEO was previously this bank’s division CIO who had terrible track records: buggy and behind-schedule releases. As a matter of fact, he was let go of the bank with shame. However, he figured out the software industry's needs, set up his own company, and talked himself up to fool others. I have to admit that he was an excellent salesman. He started his company with two associates to offer ‘solutions’ to those tech companies in need. According to him, his company was one of the top 10 fastest-growing Australian IT companies by BRW and now has over 100 employees.