Agile Release Cycles

Welcome to the series "Generic Thoughts"; brought to you by "Coding Mantis"!

So we've developed a part of our software and it's time to release it. But when is the ideal time to do so and in what manner?

In Agile methodology regardless of flavour, we've learned to develop small chunks of software based on the requirements of each iteration. During this iteration, the software should be tested for its functionality, efficiency, and performance. In the end, assuming it passes the functional and user acceptance steps it's considered delivered and it's time to release it. And this is the part where it gets confusing.

Depending on the needs of the company or team we're working in there might be different strategies regarding the release cycles. I've seen teams release a new version once per year, twice per year, six times per year, you name it. It's all based on the point of view of the team or company and some facts that whether we like it or not dictate the frequency of these releases. Some find it logical to release a new version once a whole set of features has been delivered while others would settle for less.

In my honest opinion, the sooner the code is released and gets out of our hands the better. This approach cuts down on maintenance effort and costs, makes releases easier and reduces the risk of something going sideways as well as the stress surrounding a release; truth be told, releases are stressful.

On the other hand, keeping code stashed in a box that keeps getting filled with more and more features because everyone wants their feature released as soon as possible and everyone considers their feature to be a top priority leads to problems. It's a classic hot potato situation that unfortunately almost always blows up in the engineer's face. In scenarios like these, the path forward starts to fork with one way heading towards developing new features and bug fixes that never seem to stop coming our way, and the other goes towards a dreaded place of maintaining the aforementioned box of goodies and praying to whomever deity that the deliverables themselves won't diverge and put us between a rock and a hard place of merge conflicts, missing or duplicated code, and despair.

It's, unfortunately, a mindset issue and things like these don't easily change, but in the hopes that they will, here are my two cents on how I believe the release cycle could be improved, if not fixed.

Feature flags & SOLID!

Yeap, I said what I said, SOLID; it seems to be everywhere, right?

By following Liskov's Substitution Principle and programming to a supertype with interchangeable concrete implementations we can direct the flow of our code by simply flipping a switch, or many. And how do we do that? With feature flags. We basically "inject" our code with some condition on startup or whatever stage is suitable as per our stack and needs and leave the rest to our code. Of course, this solution does not come cheap and it's surely adding future technical debt to our backlog in order to keep our codebase tidy. But everything comes at a cost.

Our code is now set for the next phase, which is a bit more difficult; changing the release cycle.

As soon as a feature is delivered, it should be immediately released to production regardless of whether any external dependencies are ready for it. Remember, our code is now modular which means that if all went well and everyone's ready, the feature will be functional in production otherwise we flip a switch in the configuration and the previous version will come alive. Simple as that but beware to not abuse it.

What do you think about the subject?