Software Development Is Unlike Construction

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?