Just Say No

I came to software engineering as a systems engineer so you might reasonably expect that I would be an enthusiast for the many ways in which software developers can learn from other engineers. This is correct, but only partially. As time has gone on, and frankly, as I have become more of a computer scientist I have become more sceptical about analogies drawn between software engineering and other engineering disciplines. This is particularly true of analogies to the 'built environment'. Constructing a software system is not like building a house, a tunnel or a bridge, except at the highest and thus the least meaningful of levels. These analogies, to which I have myself been more than tempted, can in fact, be dangerously misleading.

Software is not the same 'stuff' as that from which physical systems are constructed. Software systems differ in material respects from physical systems. Much of this has been rehearsed by Fred Brooks in his classic 'No Silver Bullet' paper. First, complexity and scale are different in the case of software systems: relatively functionally simple software systems comprise more independent parts, placed in relation to each other, than do physical systems of equivalent functional value. Second, and clearly linked to this, we do not have well developed components and composition mechanisms from which to build software systems (though clearly we are working hard on providing these) nor do we have a straightforward mathematical account that permits us to reason about the effects of composition. Third, software systems operate in a domain determined principally by arbitrary rules about information and symbolic communication whilst the operation of physical systems is governed by the laws of physics. Finally, software is readily changeable and thus is changed, it is used in settings where our uncertainty leads us to anticipate the need to change.

The software industry is quite different from other engineering industries. Because software development is pretty much all 'design' with extremely limited 'manufacturing' and 'logistics' we cannot look to the organisation of those industries for much by way guidance. Indeed, the structure of the industry, for example in the built environment, has been largely determined by historical factors and may not in fact be the best way to organise to serve its own purposes. There has been a habit of dwelling on the failures of software development contrasted with an idealistic picture of other engineering disciplines. Architects and civil engineers often build things that require extensive patching and maintenance. Certainly where they build in complex environments and with extensive requirements for interaction with people the problems they encounter seem indistinguishable from those that software engineers experience.

For all these reasons we should adopt considerable caution in allowing casual comparisons between software and other engineering disciplines to go unchecked. After all, and by way of a warning, we borrowed the 'waterfall process' from traditional engineering practice and that has not worked out too well for us!