[turnsout]

I agree—I've used the analogy in the past, but I don't anymore. The reason is: with new home construction, there's a very clear move-in date. You can make additions or renovations, but most people are not constantly changing their house.

However, in software, you need to continuously work on the product—and it's not just routine maintenance analogous to cleaning the gutters or changing the air filters. In software, it's possible to launch ("move in") before most of the rooms have been built. In software, you can use a library or API and start with a skyscraper on Day 1.

The analogy just doesn't work. It tells clients/stakeholders "this is a tough project but it'll be over someday, and you'll never have to think about construction again."

[skriticos2]

Oh, the analogy does work. Every construction needs to be adjusted at times. Sure, not as often as software, but new regulations and the passing of time is eating at the substance. After a couple of decades most buildings tend to need major overhaul and that's not much different than software. Even the reasons are similar (e.g. new building codes, energy efficiency standards, obsolote tech stacks - think asbestos and lead pipes). Especially if you live in an area where the city scape needs to be preserved for historical reasons, houses behave very similar to software - just on a different time scale.

[turnsout]

> After a couple of decades most buildings tend to need major overhaul and that's not much different than software

Respectfully disagree. Software is like building a house, and then needing to build more rooms every month forever, and every few years having to tear it all down or completely rework the foundation.

[skriticos2]

Guess it depends on the software. I have seen enough business critical software that was built 15 years ago with the developer having long left the scene and nobody having any idea on how it works internally (much less skill to actually change something).