Unitarianism in Software Deployment

Unitarianism connotes belief or desire for some thing to present a single aspect. For example, in the religious sphere belief in one God with a singular personality, in the political sphere perhaps a government of national unity, and while not explicitly used in fields like technology and systems development it could be taken as the aspiration for a single version of a product. I'll apply the term unitarianism in software development to refer to the assumption or aspiration that a product should have one authoritative version. One idealised and best version of the product that supersedes its predecessor versions, its antecedents.

Unfortunately for the aspiration of technological unitarianism, an inevitable and usually undesired consequence of software development is the fact that it is rarely finished, on-going development projects produce multiple releases of the core product, albeit releases of different versions. Variations in software versions may be minor or significant, sometimes so significant that different versions no longer work with each other or with their different data/objects. Conventional management and engineering thought considers version management to be a compliance issue. Switching version is relegated to the status of a 'data migration' problem but we all know this is not the whole story; objects may need to be regenerated, operation with existing systems may need to be guaranteed, users and customers may need to adapt, even transform, their work activities.

In the past clever object versioning schemes have allowed some systems to be patched incrementally ad-infinitum: IBM is particularly notable with its system of patching by applying PTFs (Program Temporary Fix) on mainframe, Microsoft with its service packs, Apple and its Updates. New releases of the main product would include changes commensurate with patches within their architecture, while existing systems could evolve continuously, sometimes without needing to be re-initialised or restarted.

In terms of the management of source code and the underlying software architecture we see in recent years the increasing use of the term "technical debt", indicating that a product has been patched and extended incrementally for so long that it needs wholesale "refactoring" to make its source code manageable or comprehendible again.

The practical reality of developing and keeping multiple versions in synch is usually considered to be a problem of "porting". Porting is the recompilation and rewriting of a single product for multiple platforms. Platform could be construed as computer (architecture) plus operating system combinations, competing software platforms (e.g. browsers), devices (mobiles), or running/execution environments (shells, IDEs) and other software environments (e.g. word processors, databases, social media, etc.).

Whether as software source code or objects the most recent build, the most recent release is usually considered to be a unified version, the most current and best available. Consequently customer-Product migration from one product version to another is generally treated as a technical and compliance issue. A matter of keeping up with the latest version.

However, on the matter of unitarianism and the holy grail of a single source code and object, the latest and greatest available to all at all times, no old versions - the 'technology' is a bit of a red herring. Why not have two or more products on two or more platforms? Yes you want them to be as similar as possible and perhaps ultimately allow for a grand unification/simplification. Compile, build, package and source code unification at some point in the future may well benefit your firm by making maintenance and new development more efficient. But it comes at a price, the cost is complexity, indirection, and further convoluted inter-dependencies on yet more versions of "other" software (usually sourced from 3rd parties). Unitarianism is a holy grail, and probably unachievable.

Ask yourself, what is the value of a single build, a single platform, a single architecture? Changes and differences are after all inevitable if you release for other platforms. Embrace the change, embrace the difference, allow for multiple versions, just be sure you know what they are and why you have them.

Notes for further reading

• Software maintenance and evolution: a roadmap. Bennett & Rajlich, 2000.
• Software Maintenance Maturity Model (SMmm): the software maintenance process model. April et al., 2005
• A Framework for Software Product Line Practice SEI. Currently V5 (is there irony in the idea of versioning product versioning policy?) (also see slides at www.cs.helsinki.fi)
• Experiences with Software Product Family Evolution. Riva & Del Rosso, 2005
• A Cost Model for Software Product Line. Böckle et al. 2004
• Open source software maintenance process framework. Koponen & Hotti, 2005
• Issues in Software Maintenance. Lientz, 1983
• A field study of the software design process for large systems. Curtis et al. 1988
• Salion, Inc.: A Software Product Line Case Study. Clements & Northrop, 2002
• Software factories: assembling applications with patterns, models, frameworks and tools. Greenfield & Short, 2003
• Software Product Lines, and software platforms - Yaser Ghanam at InfoQ on Mar 07, 2011
  

Bravely open up

I think it takes a different attitude to show us the inside, inside the 'sausage factory' so to say.

The following from the Twitter engineering teams illustrates what I mean

http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

Admit it, it's probably unlikely that the product - no matter how well engineered - accounts for the valuation of technology firms. You might as well be 'open' because people leave, they talk in pubs, share their war stories with college mates. Your big secret isn't going to stay secret for long (shades of Wikileaks). By way of explaining why I think it is good for corporations to be 'open', consider the good of this reflection on the dev history of a service: The Evolution of the Flickr Architecture http://t.co/lDZdgn0.

What is lost by making this information public?

Back to the Past (not the Future) Again, Google even

In other words, history repeats?

Why do so many of Slacy's recommendations to Larry Page suggest the reality inside Google is a growing creeping organisational sclerosis? (Slacy's Blog)

Slacy provides a quite comprehensive list of problems and recommendations, many of which stem from the problems of success (i.e. scale issues, complicated interdependent products, a growing need for communication and understanding but size itself becomes the obstacle).

Are innovative organisations inherently self limiting? Is there a certain inevitability to Christensen's idea of the innovator's dilemma, that one organisation cannot be all things to all product or service innovation and delivery? Time to spawn independent subsidiaries maypaps?

Notes:

Christensen, C. M. (1997) The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail, Harvard Business School Press.