Many houses are actually built without knowing the final design, especially in informal settlements in the Global South.
It's referred to as incremental building or incremental urbanism. What starts as simple structure (e.g. a shack) will develop over time into different more formal types of housing. It's an approach to housing that works well with precarious financial means, shifting regulatory environments, uncertain land tenure, changing household size or the lack of building supplies.
Maybe the guy who designed that church had a clear idea of what it would look like when finished, but i doesn't look like that today!
The plan is never "final".
There is a TV series in the UK called Grand Designs where people build their own houses. Nearly every cost and time overrun is down to making stuff up on the hoof. The few projects that are on time and budget are the ones that decide everything upfront.
I must disagree based on the number of residential homes turned into businesses, large scale remodeling, or tearing a house down to rebuild. All these fit well into the analogy.
ps. And even modern buildings suffer from this, like the projects where the requirements change all the time. Like Irelands new children's hospital, that should have cost just a couple of million Euros and balooned to billions. Construction projects are somemites done exactly like software development projects with all the fallout that comes with it. Same story with the airport in Germany (BER).
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."
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.
Well, every analogy is inherently wrong at some level of detail. Find an analogy you think is appropriate and zoom in further and it will break.
No analogy, metaphor, or general comparison is ever perfectly isomorphic with the target. As a function of communication, the mark of a good one is if your audience understands.
e.g. "We did not know where to put the piping at the start, so we put it on the outside and now installing a new restroom is sort of tricky."
The house analogy makes the waste understandable, if you accept to compare design errors with late design.
Toilet in this analogy cannot be moved, because it was originally decided, that it will be locked and didn’t invest in mobile toilet. Which was reasonable, but highlights lack of vision for the final product.
I don't think the point is that the toilet can't be moved – it's just expensive and disruptive to do so.
Nobody starts building a house without knowing final design.
I would argue the exact opposite – literally _every_ house is built without knowing the final design! Who knows what someone is going to need or want in the future? I'm writing this from a house that was built prior to the existing of indoor plumbing!
The sheer number of houses that have additions, bathroom renos, kitchen renos, walls blown out, basements apartment added, second floors added etc. etc. makes their claim ludicrous on the face of it.
In software we are often taking an existing design and modifying for new requirements. The house analogy is excellent for explaining WHY one thing is easy but another is hard.
I don't suppose that everything works entirely according to plan, and of course there is no way that every future change request can be anticipated, let alone accommodated in advance, but for all practical purposes, this shows that if one is prepared to do what it takes, one can start the construction of a house knowing what you are going to get and with a detailed plan for getting there.
Computational technology has a particularly broad and active leading edge where unknowns are being tackled, but even so, most software development is nowhere near that edge.
The original point about houses is that with software, similar-seeming changes can have greatly differing costs, on account of what is hidden from the users' view, and I think the analogy works very well in making that point.
This is exactly the problem in most software projects.
E.G. if you want your instances of "people" to be active, we're now capped at roughly 8 billion, since 92% of instances have already been garbage collected in this run.
I would still recommend planning a Long integer, just to get yourself some room for error.
I don't see that one much on HN, but it's rife on Twitter.
Software has very little bounds to physical world, comparing to actual architecture. Most of the bounds rise from ideas.
Toilet in this analogy cannot be moved, because it was originally decided, that it will be locked and didn’t invest in mobile toilet. Which was reasonable, but highlights lack of vision for the final product.
And this is the biggest difference with architecture. Nobody starts building a house without knowing final design.
While software is the opposite.