My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox

EclipseCon

March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture

Catalyst

July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response (http://t.co/KrN8XNWg) to the @mreinhold #jigsaw announcement (http://t.co/9YvcDdqC). 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. http://t.co/9YvcDdqC. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

Internal & External Releases

Filed Under Agile, Development |  

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.

Comments

2 Responses to “Internal & External Releases”

  1. Anders Sveen on February 10th, 2009 2:36 pm

    Something like this is not possible without a great deal of automation and automatic tests. It is not the only thing that is requred, but a big part of it.

    Automate build, release, test, deployment, database upgrades etc. Jeff Sutherland said once that the reason they can push releases to customers at Patientkeeper is because they have one push deployment.

    I always automate as much as possible, those small manual tasks that you do are both sources for errors as well as resistance for change.

  2. The Project Date - Revisited! : Software & Technology @kirkk.com on July 21st, 2009 3:08 pm

    [...] The date makes agility counter-intuitive and encourages development practices that we know don’t work. Removing the date makes agility intuitive. Seems kinda far-fetched, heh? I’m not so sure. Having thought about this for a while, I’m not convinced it’s too far away from the notion of internal and external releases. [...]

Leave a Reply