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.
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.
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?
No one would ask an architect to add a third basement to an already complete skyscraper, but it happens in software all the time.
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.
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.
"Where do you store it?"
He'd have responded: "In the cloud..."
Yes and no. Sometimes non-coders just want you to throw together a prefab house.
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.
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.
I came up with that metaphor on my own, and didn't know at the time that this is a pretty common metaphor so it holds a special place to me.
> Steve Jobs would just say "figure it out".
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!)
This is very well documented
https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...
Steve Jobs e-mails Eric Schmidt (2007) -- https://news.ycombinator.com/item?id=28699873
Steve mostly realized the good engineers want to work with other good engineers, no matter what they are paid
He didn't actually give people "budget"
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.
* yes yes caveat caveat
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.
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.
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.)
> "figure it out"
that's the kind of motivation that leads to someone making Armchair Toilet
https://i.pinimg.com/originals/ce/11/34/ce1134ca396e43f55c84...
If the “why can’t we do X” is “because we’re a team of 4 and already overburdened” there may not be any practical solutions.
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.
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
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".
See: the full rewrite/retool
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.
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.
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.)
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.
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.
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.
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
Unfortunately, the part after the "can't you just" is rarely helpful.
“Can you just…” sums it all.
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.
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.
I think it's not an uncommon opinion. And of course, Adam Savage is always great.
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.
You're there because you are reliant on their expertise and can't just do it yourself. Otherwise you'd be doing so.
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.
See also why estimates aren’t actual costs. Every plumber runs into this constantly. Sorry you have a crushed sewer line add a zero to the cost.
I'll be keeping this on file, thank you.
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. "
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.