On first glance, the worlds of construction and software development could almost be seen as polar opposites. Macho vs. nerdy. Physical vs. virtual. Finite vs. ongoing. High vs. low material costs. Construction builds one building at a time whereas software can be scaled. Etc.

But the other night I was talking over a socially distanced backyard cocktail with my friend Chris who has a large building company and we got into an interesting chat about the similarities in what he does on construction projects and what I do in software projects.


Nothing New About The Construction / Software Analogy

Construction has obviously been around a lot longer than software design. As the second one to the table, folks in software development have adopted the language and terminology of brick-and-mortar building: Architecture, design, projects, foundation and many more.


Premature Death of the Analogy

Yes, it's easy to poke holes in the cross-industry comparison of construction and software. The rules of physical construction rarely change. They don't invent new material like wood & steel every 3-4 months. You can convert existing buildings better than existing software; there are plenty of dental offices that used to be IHOPs or Der Weinerschnitzels whereas you can't really adapter food cashier apps to record medical information.

But let's relax our standards in comparing the two industries. Analogies are just meant to be intellectually helpful exercises to apply principles from one concept to make the second concept a little more understandable.


"Waterfall" Vs. "Agile"

Quick explanation of Waterfall vs. Agile:
- Agile: ("iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams" definition from cprime.com)
- Waterfall: ("linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion" definition from indiatimes.com)

People who think and write about software in the modern environment are very quick to signal that Agile methodology has completely replaced Waterfall development over the last 15 or so years. Yes, a purely waterfall approach is kind of a dinosaur move in computing projects. But I can tell you from experience, especially as someone who needs to bid and write proposals for projects, it's dangerous to declare the need for extensive pre-project requirements as a thing of the past.

Unfortunately, I see debate, argument and passion for Agile being a big deal for programmers under 35 while folks in the industry for 20-30 years can't quite let go of Waterfall philosophies. It's a little age dependent.

And I do feel like people who really have an Agile dog in the philosophical hunt like to trash the Construction & Software analogy.


Value Of Individual Team Members

I've seen some articles from software types like me who try to poke a hole in this long-running analogy by saying that there are superstars within the world of software, whereas people who work with their hands are all roughly as skilled as each other. I can tell you right now, those sentiments can only come from people who've never worked construction.

I remember my last day working construction, tarring a roof in Colorado on a very hot day at age 24. When I collected my check at the end of that job, I vowed to myself that I was going to spend the rest of my life working inside, at a desk, in air conditioning, using my mind. And I stayed true to my word.

Although my building career was really only about a year long, even that was enough to tell me there is a H-U-G-E range in the quality of carpenters and day laborers I saw on the job. If you know how to hang a door well, make smooth drywall quickly, or build a non-leaning staircase ... you'll find work whenever you want it in any economy; whereas if you need supervising to frame a basic wall, you might only find employment from your brother-in-law.

There are star programmers too. But that just reinforces the analogy.

And if you think that computer programming has "rockstars" where construction doesn't, reconsider the status (and salary) of a great architect.


Change Requests

This is where my friend Chris and I bonded the other night. Change requests are so common to both fields. Customers change their mind a ton in both cases; I'd only give construction a slight nod of having new ideas or changes being destructive to a project. It's not great, both in software and building construction.

And it doesn't have to be coming from a flaky client/customer. The what's-possible can require changes. Building a house, you might not have planned to see such bad drainage in the ground; while on a project you might not have realized that the microservice you were planning on using for API data starts to hang at a certain volume until you get into that sprint.


Building For Future

Talking to Chris, he was talking about future proofing things in buildings. He used to feel like he could smartly predict running more ducts that necessary would be helpful down the line in case a future add on wanted to be used for a new purpose (like an additional bathroom, or move of a laundry room, etc.) But in his experience he's found that no matter well intentioned he is at the design phase, he wouldn't accurately predict what would happen in 10 years ... e.g. for that extra laundry room, perhaps in the future Amazon's laundry service renders laundry at home to be a ridiculous idea ... yes, an extreme example but one that shows how the basics can change and not just in computing.

Chris was asking me how much I can anticipate future changes. That's an area where I think programming is relatively easier. Just make everything pretty modular (well defined, with specific inputs and outputs) and you can be pretty adaptable.


Running Over-Budget & Over-Schedule

I think if you've experienced both a construction project and a software project, then you're quite aware that both tend to go over budget.

And do you want to know when a physical construction project starts to get more "Agile"? When you're running out of time and money, it's time to throw some good ideas overboard - forget the concrete sinks and just install some cheaper traditional porcelain.


The Takeaway

Again, comparing construction and software is an analogy. Nothing more. Use the analogy if it's interesting and/or to think about things in a new way.

But if you're bent out of shape that people still want to use this analogy because Agile has revolutionized software or buildings aren't "scalable" I just have this quote for you from the movie Stripes: Lighten up, Francis.