Human beings are animals that love a good metaphor. Maybe penguins love metaphors too, but we haven’t built an MRI small enough yet to know. By viewing one action or object in light of another act or model, we can bring about moments of satori and enlightenment that lead us closer to optimal states. From philosophy (google the Allegory of the Cave, the Leviathan, etc) to business, almost every aspect of human thought involves, to some degree, taking a concept and thinking about it in a different frame. It’s useful, it’s natural, it’s a requirement.
But there comes a point when metaphors cause more trouble than they are worth.
And I’m here to tell you: Building software is not like building a house.
But I’m jumping ahead – before we get there, a quick note on the most pervasive and horrible software metaphor of all time: the waterfall.
One of the great ironies of modern software development is that this waterfall is often presented as a viable alternative to Agile practices. In fact, for over 30 years it has been known that waterfall is inherently risky. From Wikipedia:
“The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, although Royce did not use the term “waterfall” in this article. Royce presented this model as an example of a flawed, non-working model.”
Waterfall gets the steps right, it just gets the number of times they are taken wrong. Design and implementation aren’t actions you take once on a quality product– you iterate through them continuously (as you should testing). In other words, waterfall conflates valid aspects of software design with artificially segregated phases of construction, which is where it fails. Stakeholders and software are fickle and unpredictable, because like a quantum subatomic process, the very nature of observing and interacting with a functioning software product collapses its UI state.
See, that was a bad software design metaphor– I was just seeing if you’re paying attention.
So, let’s get back to building a house. Programming jokes aside, software development shares a few things in common with building a house, in that coding is a craft (like carpentry) that can be learned, and that like carpentry, you have masters of the craft. And like building a house, much of the process has been standardized and industrialized in the last 40 years.
I asked my father-in-law, who has built dozens of houses, about what the biggest change on job sites has been in the last 40 years. Without hesitation he said “the nail gun”. Suddenly building a house took half as long.
Modern frameworks, including software design processes themselves, are the nail guns of our industry.
Notice what I’m talking about is how the people who code are somewhat akin to those who build homes. But the actual object built? That’s where the metaphor poops the metaphorical bed. A house starts with a blueprint that more or less is followed to completion and success is determined by cost and adherence to the blueprint. But building software that adheres to a global, rigid plan that is entirely laid out before interacting with real-world implementations or prototypes of each component part is not only risky– it’s a waste of our time. Building anything non-trivial and unique requires another kind of metaphor, which I’ll be exploring in coming posts.
Part 2 will cover some other problematic software metaphors around dev teams and team management.