Musing on Construction as a Metaphor for Software Development

We often use building construction as a metaphor for software development. This time around, I explore the aptness of this metaphor a little bit in light of my own background in both.

I grew up in a construction family. My stepfather owned his own glass and window business while mom ran the office and did the estimating. I started pushing a broom for them and by my junior year of high school was estimating small jobs and helping estimate large ones. I eventually moved from working on structural windows to Microsoft Windows and found some of those same planning and estimating principles applied. As I built more and more software systems, I realized many development team members, project managers, and stakeholders viewed a software project the same as a building project: it was all about the “done” date and the “end” of the project and thus forming “the plan”. The more rigid the development process was that the organization used, the more I realized how much construction projects and the software development lifecycle have little to with one another. I can’t really blame us, the only language we had to describe software development management was inherited from construction and other physical project management philosophies and thus those became our metaphor. Collectively, we failed to see the differences because the similarities were too enticing. We even call people who design and build software “architects” and “engineers” (that’s maybe a topic for another time). The real problem with this? Few people in the software industry have real experience with construction and don’t know when that metaphor starts to break down.

Buildings have to work with real physics and real geometry. That’s both a constraint and a benefit. If you are building an office building, you’re going to do someting like set an expectation for number of people who will work in that building and then start working out details. Just with that one input, you can begin to determine how many bathrooms you will likely need, how much parking you’ll need for a suburban vs urban building, and so on. Given that, you have a basic number of square feet/square meters that you will need and can then consider possibilities for building sites. Once you know the building site, you can establish a foot print (the area of the ground floor) for the building and number of floors. That then lets you fill in other blanks like how many elevators you’ll need and so on. I am dramatically oversimplifying building design, but I am doing so to show that much of the process of creating the requirements for a building proceeds from a known set of questions. Cost will still vary with how fancy you want to make the building and that can also increase square footage quite a bit, but simple fact is that you know if you have so many people working in a building, you know you’re likely to get so much poop in a day and can plan a sewage system that can even handle Taco Tuesday.

We may find some big issues during construction and after we move in. Sometimes you even find big design issues during construction: what works on paper often doesn’t work in the real world. This is the first area where using building construction as a metaphor for software development falls down: when we adopted what we thought were principles for building construction, too often we took a rosy view of the process. Many issues will be small and easily remedied. Others can be fundamental: my family built a house where the foundation was made 2” larger. That seems like a small difference, but it meant additional lumber had to be ordered and we had to keep compensating for that difference from the plans as we went up. The Aon Center (formerly the Amoco Building) in Chicago is notorious for the failures of its marble cladding, the John Hancock Tower in Boston had windows blown out just by changes in air pressure and temperature.

Well then, you say, construction has bugs just like software. It’s easier to fix bugs in software because we just need to change code, right?

I am not sure that is really the case. The Aon/Amoco and John Hancock buildings required very expensive fixes but the fact that they’re so notorious is a sign that most buildings encounter much smaller problems. When we compare building “bugs” to software bugs, we are failing to realize that a lot of building “bugs” get fixed almost without a thought. Bad door knob? Order a new one and put it on in a few minutes. Need to fit seven people in the conference room that has six chairs? Grab a chair from another room. Garbage can in the way? Move it.

In each of those cases the fix was quick once the problem was identified. There wasn’t a whole followup process and only one of them (the door knob) even required a process to identify the problem and execute the fix. The others were just users adapting their environment to their needs.

In software, resolving a bug or change to requirements is a different matter. No matter how small the change, there’s more that needs to happen. Let’s say the dev can fix the code in just 10 minutes. First, someone had to report it. There is rarely a “just grab another chair” solution for the user when they find the system isn’t meeting needs.

User identifies the problem/change.
User reports it.
Product team identifies what is needed to implement it or that they need to do more research.
Product team prioritizes it.
Design the change or debug the problem. This may require a lot of research and discussion.
Identify whether this change breaks anything else.
Developer implements the change.
Developer tests the change and gets it reviewed.
Someone else tests the change.
A build and release process gets executed.

That is is a lot of work for temporary changes in requirements that are analogous to needing seven people in the conference room with six chairs. The development team usually ends up asking the user to just find a workaround that doesn’t involve changing the capabilities of the system (someone stands?). The team then watches to see how many times they get that same request and if it comes up again, it may become a feature in their backlog.

And that brings us to the real difference between construction and software development: software development isn’t even properly classified as a project. Projects have begin and end dates. Development of a software system, especially one custom built for an organization, is almost never done¹. If the system does not continue to evolve then it is either a tiny system with a tiny purpose or it does not keep up to the ever changing needs of users (organizations that don’t change usually end up dying out). I would say it is also possible that is was ridiculously overbuilt and thus anticipated every possible need, but then it cost more than it should have because it now also has unused features built in anticipation of needs that never happen. It also probably never actually shipped. Besides, how do you anticipate regulatory change and global pandemics?

To wrap this rambling up: big changes to physical structures are expensive but we can make small changes in our physical environment with so little disruption that we may not even realize we made a change. Especially for short term events, we just adjust and move on. With a software system, there’s a minimum cost of a change that we just never really escape unless we decide to just ignore the problem.

Got feedback? Know me personally and want to see me elaborate something we’ve discussed in person? Shoot me a message on LinkedIn or Mastodon @[email protected].

About this article’s image: I created Viceroy Tower, at center, using Fusion 360. The “loosely sketched” buildings around it were generated using the Adobe Photoshop “Strawberry Letter” beta’s AI generation capabilities. Viceroy Tower itself is available at printables.com along with someother buildings I have designed for small scale wargamers to print at home on 3d printers.

Allan Kelly lays out this argument in Project Myopia ↩