The Rules of the Release Game
As humans we tend to optimize our experience in ways we think will bring about the most favorable outcome. As workers we tend to work in ways which we enjoy and we believe we will be rewarded. As software engineers we tend to work in ways that we believe will get the best possible product to the customer and the best possible performance review for our work.
Software release processes take a long amount of time. They can take days, but often take multiple months or even years. However, from my own observation there is one easy way to slow down a software release: change the rules of the game in the release process.
For example, a software release enters the QA department with a certain set of features. While in QA, it is decided that an “essential feature” is missing. The software release is then ejected from QA to move to further development. Once the development is done it enters QA again. This time it releases, months late to the customer.
The same scenario could have played differently. The software could have entered QA. When the “essential feature” conversations, the software product proceeds through QA uninterrupted and releases. Then the “essential feature” could be added to the product and released in a seperate cycle. This way the customer gets the development they already desire, as well as the addition of the “essential feature” when it releases later.
What happened in the first example, is that the rules of the release were changed while in the release process. This caused the release to stall while every member of the team readjusted for the new rules. If the release had simply kept a consistent rule-set, then it would have gone out devoid of the “essential feature.” Once the product had shipped, a new process playing with the new rules would have commenced.
I believe that one of the most demoralizing things for an engineer to get stuck in a rule change situation. They hear that their code is going to ship in a few weeks. This causes them to rank up, and creates a sense of urgency. The urgency is driven by the reward of releasing their code to the customer. When the rules change, their code does not release. They then slow down to adapt to the new rule-set. However, now something is lost. They cannot find it in themselves to ramp up again for the next release. The light at the end of the tunnel has grown dim.
In conclusion, I believe that one key premise for software releases is change as little as possible towards the end of the release, especially when the product is in QA. It’s just dangerous to change the rules of the release game.