Software and Construction – No, It’s Not the Same

Krista Trapani DevJam News, News

Nearly everyday someone compares building software to building a house, and nearly every day that analogy proves to be a poor one. “Well you see first you have to dig the basement and then…” Although clear and easy to explain, I believe this analogy is doing our industry a disservice. Software is not like construction; what we are doing is much more complex because simply it is always changing.

Software is dynamic; construction is static. We don’t want bridges to shift and pivot over time; in fact that would be super bad, but we expect software products to be maneuverable. Construction follows known and established patterns that were established thousands of years ago. Software requires innovation and responsiveness to constant change in infrastructure, technology, and ways of doing things. The artifacts of construction are built to stand the test of time while software is built to respond to change and to pivot on a dime.

All those things being said, I recently had one of the biggest differences slap me in the face. Construction is scope-driven while software is date-driven. This affects our mindsets to the very core and means that not only can we not build software like we build houses, but we also shouldn’t define and plan software projects like we do construction.

It all started innocently enough. My dad and I set out to do some light remodeling and DIY work at my new house. The previous owner had trashed the place, and we were looking to make it inhabitable again.

My father and I are both engineers and have led complex projects in our respective fields, but dad is a civil engineer with a deep background in construction. I’m a software engineer turned product manager who can barely hold a paint brush. Our approaches to this project were very different.

We both in a sense inventoried what needed to be done and roughly had the same vision in mind. I had mentally already begun to prioritize things and even defined an MVP around the absolute minimum amount of work required before I could move in. Before we even began, I was making mental choices about what I would cut when we ran out of time because in the software world you never get everything. I was seeking to ensure we got the most important work done first.

Dad didn’t waste time thinking about stuff like MVP’s and value. In his world, the project isn’t done until it is done, and the sequencing of work was more aligned to starting the activities that would take the longest first. He jumped in and literally proceeded to tear up the entire house. He started about 15 different things all at once. This included taking down doors, tearing out carpet, banging large holes in the wall, taking baseboard off, removing appliances, and more. This whole act caused me to have a complete melt down – talk about not being in a releasable state.

We got into a not so friendly conversation about it. I expressed my concern that we might run out of time, and I would be stuck with a destroyed house. He assured me that he wouldn’t leave until the work was done (we won’t cut scope). He explained that it’s more efficient to make one big mess and do the work somewhat in parallel versus the starts and stops of taking it one thing at a time.

In the end, he won of course because hey, it was construction and not software. A waterfall approach made sense because the work was known, static, and scope-driven. I left the project with a fixed-up house and a new perspective on our different approaches to engineering.

Had this been a software project our approach would have been the wrong one. By starting so many things at once and working them all “big bang” style, it would have taken a significant period of time to “put the house back together again.” A lot could have happened in that timeframe; the market could have shifted or user needs could have changed.

The other thing that really struck me was my mental focus on preparing for time to expire. I thought back to how simple it seemed to my dad that the project wouldn’t be done until it was done. We never seem to have that luxury in software. The project typically ends when someone tells us we are done, the release date arrives, the money runs out, or the competition forces us to market. I can’t recall ever being on a project where we delivered everything we intended to.

Software friends, especially product managers and leaders, we have to do something that folks in construction don’t have to do as much of. We have to make product choices. We have to make them early and make them often. Those choices – choosing where to start, choosing how much to start at once, choosing “just enough” to build so we can validate our experiment – all lead to our potential for success when the clock runs out.

These choices fuel iterative delivery and more importantly continuous product learning. If only it were all as easy as construction; however, I think what we get to do is way more fun, and we don’t have to paint anything.