Hacker News new | ask | show | jobs
by citizen-stig 637 days ago
I personally think that this kind of analogy is inheretenly wrong.

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.

12 comments

> And this is the biggest difference with architecture. Nobody starts building a house without knowing final design.

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.

Is there a single building on the planet that has survived contact with residents and not changed in some way?

The plan is never "final".

Also for example the imperial palace of the Habsburg dynasty: https://en.wikipedia.org/wiki/Hofburg
There are design patterns for "incremental building", such as mounting pipes and wires on the surface of walls, ceilings and floors instead of burying them in concrete. Being able to reorganize a simple house easily is the "final design"; what point are you trying to make?
Point is that software is much “softer” and fluid than buildings. If comparing changing wites ir rooms layout is similar what refactoring of software is like, then I am happy for experience you’ve had!
...and if you extend the "building" phase to multiple generations or even centuries it's even more prevalent. You get a very organic & dynamic environment that many would say is a slum, but is an accurate representation of most of the software I've seen.

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!

so the civil engineering counterpart of agile development?
At least 50% of debates on HN are basically: "you said that A is a good analogy for B, but you're wrong because A and B are not literally the exact same thing."
And the other 50% are debates about the absolute magnitude of an effect or where a classification threshold gets set.
There's also "you said that the average is X. But this one specific datapoint is not X!!! How do you explain that???"

I don't see that one much on HN, but it's rife on Twitter.

In this scenario, is it GP that exhibits the behavior you’re talking about, or you (given that GP gave their own counter analogy) — or both?
Sigh… when this happens I often feel like I’m done talking to people on here, but then end up coming back anyways
Perhaps a symptom of autism?
Bah, how many autistic people can there be in one place?
I'd say the number is at least capped at about 100 billion, but that depends on how tightly you define "person" and "place" (not even getting into the specifics of "autistic").

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.

Actually, I really disagree with this view!

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!

> I would argue the exact opposite – literally _every_ house is built without knowing the final design!

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.

A while back, I visited a facility that builds prefabricated houses. Using CAD, they can, and do, create large and architecturally complex one-off designs, something that would not be possible without knowing not only the final (as-constructed) design, but the intermediate states as the modules are constructed, moved to the site (including ensuring that they can be moved to the site), and assembled.

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.

>Nobody starts building a house without knowing final design.

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've watched this show, and the process - and results - look an awful lot like software development projects. Just replace the owner with a c-suite executive.
>I personally think that this kind of analogy is inheretenly wrong

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.

Like models, all analogies are wrong, but some are useful, and they become most illuminating precisely on the boundary where they break down.
Agree. I no longer use analogies from problem domains that I know nothing about (home building, bridges, vehicles, etc) to describe software. A better analogy, I think, is search through high dimensional space.
> And this is the biggest difference with architecture. Nobody starts building a house without knowing final design

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.

Yea. Many places in Europe have historical city scape protection. Buildings that have been built centuries ago are being rebuilt internally all the time to fit new purposes and regulations. Not to mention extreme cases like the Kowloon walled city, that was basically a gigant interconnected amalgamation of buildings that housed 35000 people. Nobody envisioned what that would become when it started as an imperial fort, that's for sure. There are many reasons why building are remodelled to fit a new purpose without the new purpose even having existed when the buildings were first conieved.

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).

I like the house analogy, but I like to think of it as if the people building the house did not know how it was supposed to look (or function). This is mostly true, since very few developers know exactly how the end result (product/service) should look and function when the start coding.

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."

This is why nobody can decide if computer science is actually science, engineering, or art. It's such a vast industry that it's clearly all 3 depending on what your doing.
I think everybody agrees it is a craft. Like woodworking - it is part engineering, part art, and a lot of experience.
Ha, but to me it's why the analogy works. People don't question that we to do software without knowing final goals because, it's legit unknown, and from an external point of view the waste is not distinguishable from strait work.

The house analogy makes the waste understandable, if you accept to compare design errors with late design.

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."

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.
> 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.

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).
> And this is the biggest difference with architecture. Nobody starts building a house without knowing final design.

This is exactly the problem in most software projects.

Still, one could say that no one wants a portaloo (mobile toilet) in their living room.