Design, Develop, Create

Friday, 15 April 2011

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
Posted by at