Are we hindering our own creativity and clouding clients’ expectations of software development by using an unhelpful analogy?
It’s very common when talking about or explaining the process of software development to use building or construction as an analogy. Perhaps comparing creating a new software application to building a house or even a civil engineering project such as building a bridge. And in fact, as a relatively new industry (especially when compared to construction), as it has evolved, software development has adopted many of the terms from construction. We often talk of software ‘construction’, ‘building’ software, ‘development’, ‘architecture’. We have software ‘architects’, ‘engineers’, ‘project managers’.
What are the pros and cons of using the analogy?
On the surface this analogy has some merit, especially if using the traditional waterfall method of writing software, which is presumably where the analogies started to arise.
However, it begins to break down, at least for typical line-of-business applications, when starting to use more agile, iterative approaches. Due to the nature of such projects, the uncertainty of requirements and the need to constantly adapt and change throughout the process, software development would perhaps be more aptly named software ‘research and development’.
As we discussed in a previous blog, software changes a lot. Particularly during the initial development phase, but also on an ongoing basis. Modern systems often have complex user interfaces, designed for different types of users with differing roles trying to perform different tasks, often interacting with lots of other systems. It needs to be changed often. Whereas for example, you wouldn’t routinely move windows and doors or walls, or change the supports on a bridge.
However, this is OK as it’s ‘soft’, and software is, or should be, easy to change. Buildings are hard and not as amenable to change once built. Or at least not without significant cost. One way of looking at this is to consider the waste that accrues as a result of any change e.g. rubble. Whereas with software there is no wastage in the same way. Although there can be a legacy left in the structure of the code, which is where processes such as refactoring come in, change doesn’t result in waste in the same way and so doesn’t or shouldn’t have the same cost implications.
Coding, or programming, has been compared to the building phase of a construction project e.g. bricklaying, roofing, laying foundations etc., whereas in reality this is still very much part of the design phase and is more comparable to highly-skilled craftmanship. Software development requires analytic and creative thinking. This is also true of the architectural and structural design phase of a construction project, but arguably less so in the building phase. Whereas, the design phase is most of a software development project and in a sense, each release is a prototype.
Would clients be more open to a process that embraces change If they saw the process as being more about the design and less about the building? If they didn’t assume change as having a hefty cost or a huge potential for waste? Is the construction analogy clouding the software development process with assumptions and conventions that are unhelpful, that limit how we can work and what’s possible?
Is there a better analogy?
So, if construction isn’t actually a good analogy and if we’re still looking for an analogy are there better ones? Perhaps planning and designing logistics, or urban design and planning are more appropriate, although they are far from perfect. Also, most people are probably not as familiar with these processes so it’s not clear that it’s a useful analogy in terms of helping to communicate with potential stakeholders in a software project.
Perhaps it’s best to forget the analogies altogether and just make an effort to explain the software development process as clearly as we can, without cluttering it with assumptions that spring from comparing it to a process that is, as we’ve seen, largely incomparable.
