Internal & External Releases

A recent post on InfoQ discusses a two part article by Israel Gat that argues in favor of internal vs external releases by decoupling the engineering aspects of a release from the marketing and sales aspects. By doing so, the engineering team can release the product internally on a frequent basis and the business is free to temporally choose the release they would like to promote. I agree. That sounds grand. But in part two, the author diminishes the effort of all that goes into a software release by stating:

From an engineering standpoint, a release is merely a branch in the
code tree, representing a packaging and distribution decision.

A software release involves much more, especially if the business is allowed to freely choose which release they promote to the public. In general, a software release requires that certain lifecycle activities be performed, including build, testing, and more. The frequency with which a team can release is going to be directly tied to the ability of the team to perform these other lifecycle activities.  And there is a cost to these lifecycle activities.

In a session at Agile 2008, David Anderson discussed Future Directions for Agile, where he elaborated on these costs. The beginning and end of any value-added activity involves transaction costs. He goes on to state:

The prevailing paradigm in Western management were that overheads
(transaction and coordination costs) were inevitable and efficiency was
achieved through economies of scale (large batch sizes)

Because of the transaction costs surrounding SDLC activities, including build, test, and other release management tasks, the economies of scale motivate teams to release software less frequently. Is it really possible to adequately perform all engineering activities necessary to ready a software system for release on a weekly basis? And isn’t there a lot of waste involved in doing this if the business only chooses to promote a small percentage of internal releases? Absolutely…NOT! Dr. Gat is spot-on in that it can be done, and it should be done, but he doesn’t really tell us how to do it.

There is significant advantage to ensuring a software system is in a continuously releasable state because it allows the organization to bring the right product to market at the right time for the right customer. So the million dollar question must be this. How are transaction costs surrounding a software release effectively eliminated to provide the increased efficiencies without requiring economy of scale? Beyond saying that agile practices play a role, I don’t believe Dr. Gat answered that question in his articles. But if I were a betting man, I’d say that Dr. Gat’s teams leverage a pretty effective continuous integration strategy. Because if they don’t, I don’t know how they can pull it off.