The Construction Metaphor For Software Development
What makes a good metaphor and why the construction one works well for software.
With every mention of a metaphor, someone will inevitably complain that the person sharing the metaphor got something wrong. For example, a recent LinkedIn post led to an exchange about whether comparing bridge construction to software development was valid. While a bad metaphor is frustrating and can seem to oversimplify an issue, this post got me thinking about what makes a metaphor useful, and why, in this case, the construction metaphor made a lot of sense.
Metaphors
A metaphor only works if people have a shared understanding of what its elements are, and enough context to know what the limits of the metaphor. In Metaphors We Live By, Lakoff explains:
The essence of metaphor is understanding and experiencing one kind of thing in terms of another.
Some metaphors work better than others. For example, Argument as War works because we use phrases like “attack a position.” But you still need to limit yourself to the idea of winning, a “battle” with high stakes, etc, and not quibble about whether an argument involves “weapons” other than words. This works because most of us have a common understanding of what an argument is and some general idea of what war is. This is less true about the physical metaphors for software development.
The Construction Metaphor for Software Development
People sometimes assert that construction was a poor metaphor for software development because construction projects are planned out in detail, starting with defined requirements. On the other hand, software projects are (often) bespoke, with lots of uncertainty about what we really need.
Some might say “well, we should have well-documented requirements, and start with a fully fleshed out design” for any project. While some projects benefit from well-defined up-front requirements and design work, most of the time it’s better and easier to iterate. That is sometimes true for construction projects as well.
If you have ever been involved in a home renovation project — especially in an older house— you might have experienced this dynamic: the elements of the house are not as square as you hoped, and you never know exactly what you need until you open a wall.
The main difference between construction and software in this regard is the cost of change, which correlates with the importance of identifying issues early. Building a wall and then moving it when you discover that there is a physical or use reason it can’t be where specified. With software, it’s often more effective to build a lightweight version of an element (an interface, API, integration), see how it works (in a technical sense or in an experience sense), and change it based on feedback, rather than trying to anticipate all the possibilities. In both cases, you may not know til you see it, though with software, it’s reasonable to err on the side of iterate. For a building project, doing some analysis before you build the next step may be the better choice.
The key to success in any project is acknowledging that change is necessary and balancing the value of iteration with the cost of working that way. This is true of building both structures and software systems.
If you have never experienced this building dynamic (or didn’t hear of it from a friend), the metaphor may fall flat for you. The value of the construction metaphor depends on your experience and understanding. But don’t all metaphors? Next time you propose a metaphor that falls flat, consider what context you can add to get everyone to the same baseline. The important thing to consider is whether the metaphor helps with understanding what you want to explain.
The main point of the construction metaphor is “things change, and change has a cost.” Sometimes the cost is small enough to make an iterative building approach less costly than extensive planning and design. In others, some up-front design is the right choice.