Zen and the art of software configuration management
Less is more
Indeed, if you occupy certain parts of the blogosphere you might pick up the impression that traditional programming had died out completely, and that Web 2.0 Mashup camps were the order du jour. Battle-hardened programming cynics (the ones who can write FORTRAN in any language) might decry the lack of structure, the suggested anarchy that such approaches can bring: indeed, there is a movement seeking the re-adoption of the Waterfall lifecycle, which is frankly unlikely to attract any members under the age of 30.
Where the newcomers might have a point is that the old ways of doing things really were—and are—far too slow to keep up with what is an increasingly demanding world. Given the choice between a few hacked together scripts now, or a perfectly honed vertical app in two years time, many would choose something tending towards the former. However, we can also learn from the experience of the old hands. Like any other code, as the mashed together scripts are delivered and used they can take a life of their own, growing and evolving beyond their original remit.
Without hypothesising too much, it is not hard to piece together a few scenarios about how things will stand in a few years time. Code (scripted or otherwise) tends to become its own documentation, as people move on and others make modifications. It also tends to grow.
Often, contributions will come from many quarters, frequently geographically distributed—so multiple teams in different countries will end up working on the same pool of code, at the same time. Sometimes parallel copies of code become necessary, for example to fix a bug in one environment while maintaining the stability of another—sooner or later, such changes need to be merged back together. It is not for us to act as doomsayers, but suffice it to say that such considerations can lead to chaos, if steps are not taken to keep tabs on what is happening where.
These are not new problems, nor are they inevitable if certain mechanisms are implemented to protect against them. Collectively, these mechanisms are known as "software configuration management"; in layman's terms, this means keeping tabs on what changes have been made, to what, to ensure that a required instance of the code (the "configuration") can be created with minimal fuss. In summary, the mechanisms are:
- Version Control. We need to be able to store versions of code and other files, together with baselines—sets of versioned files that can make up a delivery.
- Workspace Management, also known as checkin/checkout, to enable files to be worked upon by specific people.
- Build Management. This involved constructing a release from a (baselined) set of files, for example by running generators or compilers, which may also be versioned.
- Process Control. The management of workflows around development, for example the stages to be undertaken before a formal release.
There's much, much more to software configuration management, particularly to take into account such challenges of multi-team working and geographic distribution, but for now the important point is this. At the end of the day, whatever the language and whatever the method, the end result is programming code. With a bit of foresight early on, many problems can be avoided later so don't leave software configuration management too late.
Copyright © 2006 Macehiter Ward-Dutton
This article was originally published at IT-Analysis.com.
Sponsored: Are DLP and DTP still an issue?