A Short on the Reasons Why
TL;DR: Construction is a poor metaphor for software development due to its non-linear nature, difficulty maintaining insight, disagreement in measuring, and its conveyor belt of opinionated approaches. There may be better analogs.
Our family recently completed a straightforward home construction project. We took down walls and extended our kitchen into an open floor concept.
The project process and progress was clear. We initially worked with an architect by drawing up plans. We then worked with a government agency to critique and approve those plans. Finally, we worked with the implementers in three phases-first, demolition and preparation. Second, structural, plumbing, and electrical. Finally, exterior cover and finish. At each point in time, the agency would review and approve the work.
The project made me reflect on my profession. While building construction metaphors are often used to describe the software development process, this is not how it works. Here are the reasons why.
Non-Linear and Mutable in Nature
Construction can be highly linear. It follows a well-defined sequence. There are points in time where diversions are required. Sometimes plan alterations are made when plumbing specifics need adjustment. Structural maladies are discovered. Or when safety realities must be mitigated when dangerous electrical splice boxes are found. With software development, there is no defined sequence and no silver bullet. We tend to run in different directions. We shore this up with the typical "sprint zero" and include numerous inspection points. We shorten the loop of the process and respond to items in that loop.
Software development is a creative endeavor that is non-linear. It is fostered by discovery with no clear middle, beginning or end. Re-work is continuous.
Insights Are Opaque
Construction progress is straightforward and visible throughout. Software development is abstract and invisible. We use demos, tools, and dashboards to make visibility available to our stakeholders and teams. At best, it is opaque and requires extraordinary effort to maintain visibility. The tools lack cross-cutting dissection, rely on imperfect telemetry, and inference in our tooling is nascent. This leads to difficulty in making appropriate decisions at proper times, leading to waste, poor software cohesion, and delayed delivery.
Our mental model of software projects have misconceptions. The reality is that the model is varied from contributor to contributor more than we think.
Disagree on Common Measures
Construction requires building in a way that is acceptably safe and predictable. There would be no way a two-story home could stand if its main structural beam were removed. However, we would be surprised at how software development projects across the finish line with malformed structures. Software development processes, development practices, and principles attempt common ground between engineers, but there is little agreement. A continuous debate has created a void of common measures, therefore, to less predictability and safety.
It is as if on the proverbial blueprints no one can agree to a consistent scale measure.
Individual Personalities Prevail
Construction is physical in nature, with clear constraints. Many past learnings have reinforced agreed approaches. But software development is not a mature industry, and therefore we do not follow a clear approach due to disagreement in measures. There is a high-level diversity in thought and approach based on assumptions. We are all exploring and learning together. There are spheres of influence that represent numerous philosophies. Opinionated decisions are made externally and brought in internally. At best, we have team-scrutineering based on perceived external community validation.
Unlike construction, software development has many voices pushing and pulling the community in different approaches. The question is, who are we listening to and why?
Conclusion
Our home construction project ended on time and within budget. However, this cannot be said for a majority of software projects I worked on. What is clear are the above items. Invisible details, glued together non-linearly by smart, opinionated individuals.
If construction is such a poor analogy to software development, other human endeavors may be more closely relatable. Scribing, music composition, gardening, and philosophical activity may have better analogs. The reasons why require study, and I will leave this up to the reader.
What are other differences between construction and software development not outlined here?
Top comments (6)
This is generally my go-to. Sufficiently complex systems are a lot more like organisms than buildings. Yes, we have a lot of control over initial circumstance, and we can do lots of trimming along the way, but we don't get to be in control entirely.
When I recently discussed toy invention with a dev, I somehow repeated a shocking hidden thought "software is like building sandcastles." Although one would think I'm being pessimistic (indeed, I can be, seeing systems become washed away with newer ones over the years), my point was clear. In a positive light software starts with little effort and cost. A single person can build amazing things, now aided by the sidecar AI assistant helping with the paired analogies like mixing, structuring, and sculpting. One person can capture the minds (and potentially wallets!?) of the beach.
Similar to something I wrote a few years ago: dev.to/bytebodger/dev-is-not-const...
Thank you for sharing this! Great analogy. You may like reading up on Fred Brooks, he has some analogies to the practice medicine like surgical team, lead doctor, etc.
I tried to read Code Complete: A Practical Handbook of Software Construction, Second Edition: McConnell, Steve but I gave up after two or three chapters.
It felt like the author made a huge attempt at wishful thinking, describing what he thought software development ought to be like rather than the impure thing it is.
Your article explains very well why the analogy falls flat.
Since we write code, my analogy would perhaps be that we are trying to write a giant wiki with additional requirements:
Thanks for sharing. For a slightly better read, try A Philosophy of Software Design.