Software is a house. The more you lean into the analogy, the better.
I often tell clients "The first thing you asked me to do was to move a dining room chair into the living room. Then you asked me to do the same with the toilet. The latter only works if we tear out all the plumbing."
Non-coders seem to understand these analogies intuitively.
I must be doing something wrong then. I’ve used almost exactly this analogy. But rather than mollify the client it leads to frustration and annoyance: they see the features as similar and are frustrated/skeptical about why I’ve claimed this new sitting feature is so different than the other one. Often goes with sentences that start with “can’t you just…”.
Steve Jobs would just say "figure it out". Way less condescending because he isn't trying to offer a solution to something that is your domain of expertise, but it also says he doesn't care if you think it's not feasible right now. Think hard and find a creative way to make it feasible. This often needs to be said because people tend to jump to the conclusion that it is too hard before they take time to think about possible solutions.
Give me the budget that Steve Jobs gave to his engineers, and I'll figure it out too.
The difficulty in what my clients are asking for is often not the feasibility but rather the time, monetary, and opportunity cost for ignoring other features.
Apple didn't pay well for most of its life, until well after iPhone/iPad success
It was not like "FAANG salaries", which started around 2011, by my reckoning because Facebook didn't agree to the "Steve Jobs collusion" with Google/Intel/Pixar (ironically!)
A budget is also time, resources, and latitude. Steve Jobs’ “Figure it out” was “I’ve given you a task, now go do what’s necessary to get it done”. This is what the post you’re responding to is referencing: the client is asking for something to get done but is not providing the resources required.
As a side note, engineers tend to be bad at couching conversations in these terms - nothing is impossible*, things just cost more or less, and that’s a decision for the money people to make.
I'm not sure this makes the idea of him saying "just figure it out" any more applicable to the rest of us (which is what the parent comment was responding to). You've pointed out that he was _unsuccessful_ for a number of decades before hitting the jackpot, and I'm dubious that the only reason he was more successful than everyone else in the long run was due to the rest of the industry just not trying hard enough. That means it was some combination of his specific skills or circumstances beyond his control, and either way, it's not really super actionable advice to "just figure it out (and either be uniquely talented or extremely lucky)".
When I think of “budget” in this context, I’m thinking about what is available to the engineers in terms of tools, resources, and time.
Where I work, it doesn’t really matter what I’m paid, we don’t have a budget to go get what we need. If I think a certain tool would help get a job done faster, too bad, I have to cobble together what I can with the tools I’ve been provided. If I think something will take a year, too bad, it’s due in a month and we’ll have an hour long meeting every day to ask why it isn’t done yet.
In this context, employee pay is largely irrelevant.
I can't tell for sure if the "ironically" refers to it feeling ironic that Facebook didn't collude, or that Pixar did collude. If it's the latter, it's because Jobs was CEO and primary shareholder of Pixar and orchestrated it's purchase by Disney to get himself a seat on the Disney board. Ironically, if I'm recalling the biography correctly, Jobs made significantly more money from Pixar than he did from his first phase at Apple.
I had a coworker who wanted a BMW more than anything. Typical young Indian male aspiration of that era (everyone had a BMW as their wallpaper).
He got the money together to buy one. Or thought he did. Forgot about insurance, being a young male and little driving history. Doubled his payments.
Also he was a terrible driver. The expensive thing about BMWs is not the car it’s repairs. Which is also why the insurance is so high. He wrecked that thing three times. He probably could have gotten his family into a better house for the amount of money he burned on that car. So foolish.
Customers live out this sort of drama all the time. They need a good used car but they want something that’ll bankrupt them because they have an image in their head. Either a dream or a status symbol.
Gordon Ramsay did a whole TV series about restaurateurs with the same mental block. They want to be successful but they don’t want to pay their dues and pretend instead.
I generally find that more resources are often the easiest thing to get and rarely helpful.
Most of the time the issue is the "9 women can't have a baby in a month" problem where adding more resources is not going to make things happen faster - in fact it may slow things down.
But the business doesn't understand that software is not like construction where adding more people really will get that ditch dug faster.
At its core software is not making a thing - it's inventing a machine that makes the thing.
If you're Little Debbie and you have a machine that makes cupcakes it's hard when the business comes in and says, "now it needs to make fudge rounds." And no amount of extra people working on the problem will get that machine retooled any faster.
Oh, I wasn't meaning to suggest that all problems are solvable by throwing more resources at it, that clearly isn't the case.
But it's super common for a team to be asked to do something fundamentally outside their scope, and the asking client/boss not realizing that they are doin g it.
"Figure it out" as a useful strategy sort of assumes that both sides of the equation are clued in about this and roughly on the same page.
"I underwrote a great team, you should be able to figure this out (stop whining about it being hard)" is a fundamentally different statement than "Why can't you just do X, how hard can it be?"
It's also worth remembering that the plural of "resource" is not "team".
> But the business doesn't understand that software is not like construction where adding more people really will get that ditch dug faster.
People tend to understand that there's an upper limit to the amount of people that can be deployed to dig a ditch any faster too
They just refuse to believe that with software, sometimes that number is smaller than they think it should be simply because people aren't physically getting in each others way
"Get a spaceship to Alpha Centauri next year. Oh, and it has to have a crew of at least 20 people, who all return safely to Earth by the end of the decade." I'll leave you to think hard and find a creative way to make it feasible.
Sure, sometimes you can re-define the goal. ("We need to know more about what's in the Alpha Centauri system.") But sometimes domain expertise means telling non-experts about reality. (Pi is not 3, no matter how much someone thinks it should be.)
I had a boss who I’m now sure had aphantasia and his two best UI people would tell him something wouldn’t fit in backlog grooming, then we’d get to spend a week showing him all the different ways it doesn’t fit before he would shut the fuck up about it.
We already “figured it out” in our heads because we are equipped to do the job. We were already doing some pretty sophisticated typesetting to make more things fit on the screen than really did.
He was sure he knew where the problems were in the org and that they weren’t him.
Since they referred to talking to “clients”, I’m guessing the problem wasn’t that the task couldn’t be done but that the client didn’t want to pay more for the additional work.
I've built you a toilet with a collection bucket that smells, needs regularly scheduled emptying into the other toilet, and it overflows anyway when you throw parties.
This resonates with me. I get a lot of "But Microsoft Office 365 Cloud does…"
I tell them that Microsoft spent a quarter of a billion dollars on that item last year, and I'm perfectly happy to re-create it if they give me a quarter of a billion dollars, too.
While I agree this is an improvement, and that it respects the agency of the worker, it’s not enough. Pushing true boundaries may in rare cases be catalyzed by an inspirational leader, but that’s exceedingly rare even if survivorship bias makes us think different. On the contrary, our tech graveyards are littered with bold bets that failed because leaders deluded themselves with yes-men.
Fuck “just”. When someone says “just”, all I hear is “I have no fucking clue”.
Just is a bitch mother that seeks to handwave away any potential problems.
If it’s just that, I’ll gladly step aside and let you do it. But if you then tell me you can’t do it, then you better sit down, shut the fuck up, and listen when I tell you something is more complicated than you think.
Adam Savage has a most excellent rant about the outrageous arrogance of the phrase, "Why don't you just..." I highly recommend it: https://www.youtube.com/watch?v=OP4CKn86qGY
My best example of this is my father-in-law. He's an absolutely wonderful man, generous to a fault and all of that. Fancies himself a handyman. But I had to stop asking for his help with around-the-house projects out of sheer anger and frustration because every SINGLE time I made a decision about how to proceed with the job or pick which tool to use to cut something, he would stop and and ask, "Well, why don't you just do X instead?"
It didn't seem to matter if I explained my reasoning, or if doing X meant redoing a hour of work just to get back to where we currently were. I even attempted to humor him by trying things his way whether or not they were going to work out. (They often didn't). Eventually it ended in me saying "no" way more often than "yes" and he would infer that I was refusing his help and he'd throw his hands up and walk away.
every SINGLE time I made a decision about how to proceed with the job or pick which tool to use to cut something, he would stop and and ask, "Well, why don't you just do X instead?"
Sounds like he spends a lot of time on StackOverflow.
In some cases, it's diminishing or trivializing the work. "I just need to do X" trivializes the amount of work that X takes and in some cases implies that the person I am talking to is not competent / capable of doing it themselves (often implying that they should be).
Likewise, "they just did X" trivializes the work that the other person does.
Its a word I ̶j̶u̶s̶t̶ don't believe adds value to a sentence.
My wife and I agreed to expunge "just" from our vocabulary, at least with regards to asking to do this. It's almost always kind of belittling, implying that the thing you're asking for is easy and obvious, and you're an idiot/lazy for either not doing it already or trying to explain why its more difficult that it looks.
I see “just” as an invitation to win the argument by agreeing with the person. “Ooo yeah good idea, I think we could. Can you help me think through this?” — And then they ideally proceed to come around to essentially what you wanted to do anyways.
When my daughter was working in her university's dining hall, the most demanding orders always began with "just". Can I just have a non-fat sugar-free vanilla latte with two pumps that isn't too hot?
to be honest, it's a flaky analogy at best. Houses are physical constructs - you can't have the toilet be physically in two different places of the house at the same time. Also dramatic changes (eg rebuilding an entire house) take more time than simpler changes (painting a wall), which isn't the case in software (sometimes a tiny change takes longer than building entire features)
A better analogy is a tapestry. Developers are like weavers, threading designs line by line on a substrate. Some task like "add a leaf to this flower's stem" can be done incrementally, but others like "move the flower one inch up" require unweaving the whole design and rebuilding it from scratch.
Doctor might not be the best example. There are tons of Facebook groups out there treating all their diseases with crystals and a bit of WebMD. Had to sit an extra 20 minutes at the dentist just this week because some lady refused the XRay and was lecturing the staff and then the dentist about how they should be able to figure out her problem with just their eyes.
It's also a bad example because most doctors people encounter are overworked, on a budget, and not very smart,* which means they're very frequently wrong.
Assuming the patient is as intelligent as the average on HN, and motivated about their health, they may well be able to learn more about what's going on with their health in the month it takes to get an appointment than the doctor will in the ten minutes they spend with you.
(* Because most people who live in cities, and most people who go into primary care in cities do so because they weren't competitive enough for one of the more interesting and lucrative specialties. It's a similar dynamic as to why most people in the tech industry that people encounter—IT help desk reps—are not usually the cream of the crop.)
This is an insult to the doctors I know who deliberately chose to do primary care because they were more motivated by service than money or prestige. For that matter, I know a developer who chose to work in IT support for a cancer research center because he put more value on helping to cure cancer than making more money. There actually are people out there who value service to the community more than fame or fortune. They deserve praise, not scorn.
It isn't an insult to anyone. I very clearly said "most" and "usually." We also have excellent IT support, done by developers, because we specifically negotiated for it. They are excellent. But we specifically included that in the contract because it is an inarguable, objective fact that most IT help desk support is not staffed with the most skilled people in the tech industry.
Unfortunately, the kind of sacrifice and selflessness you describe is not the norm in our society. As a result, the dynamic I articulated holds for "most"—just like I said.
Your post is deliberately dishonest in its characterization of what I said, and excessively hostile. That kind of behavior is not consistent with the community norms on HN. I urge you to reconsider how you interact with people here.
This isn’t a good analogy imo, and I’d argue that it’s often healthy for someone to push back this way.
I’ve been on both sides of this fence as a customer and a developer, and have at times had to straddle the fence as a PM.
The hardness of a problem does not mean the problem can’t or doesn’t need to be solved.
A client pushing back is often their way of trying to ensure that the developer actually understands what they want.
“Pushing back” as a developer is often mostly about setting expectations, i.e. “no, this is very different, won’t benefit from previous work and won’t be easy”.
All of this is necessary to gain a shared understanding, and the end result may still be that the work must be done.
IMO, the "can't you just" people do this with everyone. I can understand why, as it is sometimes effective at queuing people to keep trying and to find a way.
Unfortunately, the part after the "can't you just" is rarely helpful.
If I'm to believe a friend, who'se a family doctor, this is exactly what happens.
Especially since corona. And not a tiny minority, but a big group.
He told me that a few decades ago, there were the occasional homeopathic or other "nutcases". But that today this is common.
What I've read about this, it's a global trend, in a fly-wheel (feedback-loop) effect with mostly populism. Populism feeds distrust in authorities like lawyers, doctors, journalists. And distrust in authorities feeds populism.
There are good doctors and bad doctors just like any other profession. I have gotten plenty of bad advice over the years from doctors. Took me 2 years of going to various doctors to figure out I was having a reaction to mold. My neurologist just had me try all these different medicines, almost all made me worse, but none of them got to the actual problem. This is VERY common. Doctors so often just treat symptoms. That said, there are idiots out there that don't listen to anything a doctor says about politically charged issues like Covid. Homeopathy is mostly nuts. But integrative medicine is also often poo-pooed, but it makes logical sense to treat the whole person, not just symptoms. But I am sure there are plenty of crackpots there too. The waters are muddy my friend, not much is clear.
Yes, i feel like the biggest problems getting real treatment are in equal parts, people not thinking of the concomitant factor/asking the right things/being afraid to tell certain things, and doctors having no where near enough time to actually listen to someone and think about their situation.
I try not to fall into the first category but I've known many people who do. Though I've had many experiences with fast talking, eyes glazed, interrupt me to push the first thing that comes to mind type doctors. Once i had to fight with guy to just get him to let me finish a sentence! He changed his mind every 5 words trying to get out of there but it'd've been faster if he just let me talk! It's infuriating, I'll never go back to a doctor like that. Seems like he didn't even wait to leave the room before i was out of his mind, possibly i never even entered it
IIRC Jack “Wow” Davis (a photoshop expert) mentioned this is what his clients like to say to him: “Can you just remove the thing in the photo?” The “thing” can be the eyeglass they are wearing, etc. And he said, “come on, I’m going to come to your house and take it again.”
The reason someone is paying you cash for your time and expertise is because they cannot do it. If you can’t do it either then why are they paying you? In these situations you need to be very delicate about explaining the nature of the challenges in a way that doesn’t make them feel like an idiot for paying you money in the first place.
That’s funny because I argued with my plumber. He wanted to do a long term solution to a problem I have. It was a good solution. I said I didn’t want to do it because it was quite a bit less expensive for me to just deal with the acute issues when they arise over the rest of my lifetime.
I’m usually paying experts to advise me so I can make my own decisions and then enact those decisions. Occasionally, I will have an opinion on methods. I’m not reliant individually on any expert, even if I am ultimately reliant upon their profession. And I hire people for work I can do all the time.
Experts are often wrong. They misunderstand requirements. They don’t fully understand the system they are modifying. They can be lazy. They can consider a job or client as less important than other jobs or clients. They can lie. They can have incentives that don’t work for the client. They can be terrible at their work.
Even when experts are good and honest, they can make decisions that don’t work for their clients. My divorce lawyer was amazing when he was on the warpath, but I told him I didn’t want to take that approach generally because I knew my ex’s back would go up and we’d both pay a lot more in legal fees to achieve the same results. He was good at his job and he wasn’t wrong, but that particular method didn’t work for me.
I'm currently building a skyscraper on the foundations of a bikeshed.
Anyway, a nice idea for generative AI could be to take source code and turn it into a corresponding image of a building so managers can see what they're doing wrong.
Eh. A better analogy - the output would decide that there needs to be conduit between floors for chilled water, hot water, sewage, dutifully make several 4” pipes, and then from floor to floor forget which is which.
"No, 'c_water' means 'clean_water', it has nothing to do with the temperature, so that's why you got burnt; also 'gray water' has nothing to do with a positional encoding scheme, and 'garbage collection' is just a service that goes around and picks up your discarded post-it notes - you didn't take that rotting fruit out of the bowl, so how could we be expected to know you were done with it?"
Are they willing to pay for a skyscraper at least? I find that a lot of people expect to pay for a shed and get a skyscraper that has no maintenance cost.
Have you tried this? I bet it would work right now and look exactly as expected, a mess. The again, I gave GPT-4o some obfuscated js, a canvas rendering some buildings (shared here originally), and asked what was being rendered and it returned that it was a heart. So maybe not.
> I'm currently building a skyscraper on the foundations of a bikeshed.
Not sure if you are joking or not, but I often hear similar things and I believe that it misses the point. What constitutes a good foundation in software is very subjective - and just saying "foundation bad" does not help a non-technical person understand _why_ it is bad.
It's better to point at that one small rock (some ancient perl-script that no-one longer understands) which holds up the entire thing. Which might be fine until someone needs to move that rock. Or something surrounding it.
I like this thinking because it's a true reflection of how things work. I strongly doubt any housebuilder goes back to the architect and says "can't do that, foundations bad." They'd explain what the problem is: maybe the design is rated to a certain weight/height, or what's in the ground composition that prevents the requested changes.
We should do the same in software engineering. What exactly in our design (e.g. that Perl script that's running half the operation that we need to investigate) is stopping us?
And to extend the analogy in-kind to fit the conversation it would also be like 10 Years later all the plumbing became wireless (802.11pu) and so what was hard to impossible is now simple (cv object recognition of a bird in a photo).
Love the analogy. As a robotics (software) engineer I've long struggled to explain to software engineers why certain things are extremely hard.
I think I'll use your analogy next time, "and then robotics is like gardening. You don't know when the weather will change what wild life will come and try to ruin it, or the soil composition. At least in the house, you can be certain everything is made by human for humans, and things make sense. Outside, not so much. "
The analogy is useful to explain some changes are harder than others. However, what concrete situation in software could this analogy cover? What is the chair, what is the toilet and the concept of moving mean in this context?
Yesterday, I delivered a long-asked for feature - optimistic updates for a UI screen after a button click on Screen #1. It took only one day because the server-side logic is entirely under engineering control and the only edge cases are "their account was concurrently drained" or "the person who clicked the button is trying to hack us". Both of which will be handled when the server responds with a non-successful response. There is little to no likelihood of this behavior changing any time in the next 10 years so I ensured coupling between these components was respected with a simple comment in both places.
Today, you are asking me to provide an optimist update for a button click on Screen #2. However, that button runs business logic that is specified by multiple other users in a scripting language based on a variety of inputs, some of which are dependent on the responses of external systems over which engineering has no control. The response's fields are known in advance, but those fields' values are not.
Of course, anything is _possible_ and if we build a feature where users can specify the likely result of the external systems and build a heuristic-based analyzer for common patterns in the scripting language we could eventually get to the point where simple screens driven by this monstrosity could optimistically update. However, it will take a lot of development work and the testing effort will be high, both for the initial design of the feature and to add sufficient integration / system tests to ensure that future updates to any of these systems do not break common assumptions between them.
Honestly, I think the bottom line is decision makers need to be technical. If you are responsible for an area and are non-technical you must find someone who 1)you can trust and 2)has the requisite background such that you can fully delegate to them. Anything else is essentially irresponsible.
The only thing analogies help with is essentially to convince non-technical people who do not trust you that you aren't lying to them.
If the poster is referring to the comic, the geotagging is the chair, the bird identification is the toilet, and the act of "moving" is the effort involved.
An analogy that could more closely fit could be something like:
You have a new kubernetes cluster and some servers running code. You're migrating some services over (moving rooms). If you have a simple webapp that has no persistent storage and is containerized, the move would be simple (like moving a chair between rooms). However, if you were to try to move a webapp with login info and databases, there's a lot more "plumbing" not apparent to an outsider that would take a lot more work.
I think the analogy best captures "some things are easy, some things are hard". For instance, if I were the stakeholder and this analogy was used to convince me that moving a web app that uses a database is hard, I would still wonder what you really mean (and I have lots of experience with Kubernetes). Probably better just to say what is actually hard instead of reaching for an analogy unless you just want to get past the stakeholder's "BS firewall" easily so you can get back to work. If that is your goal, absolutely use any persuasion tactic at your disposal. However, this scenario has a massive bug: the non-technical stakeholder didn't delegate decision making to someone that they can trust.
The analogies shouldn't be needed at work for sure, but they work well for people who aren't industry and don't especially care. Eyes glaze over at anything beyond "database" but people know about moving toilets so they appreciate the analogy when you're at a family reunion or something.
Perhaps, but those people are the bug in this hypothetical. They should instead delegate decisions to someone who is competent. Obviously the real world is filled with bugs of this nature, but helpful to at least recognize where the problem stems from.
I tend to think of it as plants/trees. It starts from a single point, the main routine, and branches out its behavior over time. Branches get pruned, abandoned, merged, coopted to optimize for the nutrient gradient. I especially like the “roots” analogy i.e. it draws its strength from the parts that are hidden and difficult to assess by typical observation.
yes, but aren't we the creative gardeners/pollinators? Not to mention that software is naturally more dynamic and cross-compatible than real plants, given to all manners of chaotic mutations and grafting.
the software/architecture analogy works in many other ways, some concepts on functionality, reusability and modularity are very similar, but i guess that works for any complex system created to solve a user-specific problem
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.
> 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.
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!
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."
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.
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.
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.
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).
I often tell clients "The first thing you asked me to do was to move a dining room chair into the living room. Then you asked me to do the same with the toilet. The latter only works if we tear out all the plumbing."
Non-coders seem to understand these analogies intuitively.