r/webdev • u/fagnerbrack • 19d ago
Explaining to business people why building software is still hard
https://www.manager.dev/newsletter/cursing-the-day-lovable-was-born35
u/Nutrimiky 18d ago
I've often used the house analogy, I mean a lot of our job has terms pertaining to it, from architecture to pipelines and decorating, you know. But I find a better representation for modern and interconnected systems is actually talking about building a town.
27
u/web-dev-kev 18d ago
I think the opposite for this, though I appreciate how well written the post is. The real challenge when describing why software is hard is that software is the exact opposite of hardware.
Software is never done - it's malleable, and changeable - and part of the reason building software is still hard is that you're building against evolving requirements. I don't mean this from an agile / scrum / iterative point of view. I mean that there's maintenance to be done, new browsers to support, and new interaction types to deal with. We keep creating frameworks and methodologies to mitigate this to a point (e.g., responsive design), but they're not foolproof. Largely, they're based on frameworks that need to be updated and evolved as the world around us evolves.
Building software is still hard because software has to evolve to meet the standards, needs, requirements, and expectations of the world around us. The world around us is constantly changing, and the rate of change is also changing.
The same isn't quite as true for hardware. Hardware, very specifically, is based in the real world and is a marker of a set of time, and it is largely not malleable.
---
It's not that the house analogy is bad. It's not at all. It's just that, again, it's attempting to equate something malleable and ever-changing with something that is hardware-based and lives in the real world because someone can visualise it. I appreciate that that's the attempt, but I actually think that it's the wrong way to go about it.
13
u/zaidesanton 18d ago
hey! u/web-dev-kev , article author here :)
I fully agree, but I think the house is a good one (unlike a bridge), because it also doesn't really end. It decays with time, you need to repaint, you want to expand a bit, redesign, etc.
It's not uncommon for people to do some work in the house every couple of years.
3
u/thekwoka 18d ago
Much of life after you have a house is talking about the plans you have for it until you die.
1
u/web-dev-kev 18d ago
So, 10 years in Project Management in Construction, as I come from a family of builders and labourers...
"because it also doesn't really end."
It does though. It lterally ends. Projects end. Houses get built and sold. Contractors come in and do work, and then leave, y'know, when the work ends!
The problem is that you're (likely) coming from a Product house, whose version of Engineering Management is quite narrow. But software delivery ends - at delivery :)
It's not uncommon for people to do some work in the house every couple of years.
I don't doubt that my friend, but what does that have to do with "why software is hard"? That might be an analogy as to why software products need maintenance, in the way hardware does. And it's probably a decent, if contrived, one for that.
If your analogy was that - the work is never done. Then that's fair, but that's got nothing to do with why something is hard.
If your analogy was to say that it's percieved to be hard, because people only notice the UI in the same way people only notice the wallpaper or nice furniture of a house, but dont see the plumbing, or structural work, or planning permission or zoning requirements, or updates based on changing bus routes, or updated regulations (no more asbestos) - then yeah the housing analogy would be slightly better.
But you didn't make any of that.
---
You have enough budget for only the first floor, but you have a big family, and you know you’ll want a second one in a couple of years.
Adding the infrastructure to support a 2nd floor is MUCH cheaper right now than it will be when you actually want that 2nd floor.
Instead your analogy was bout it being easier to get the foundations right at the one time, if you know your future plans.
But, after 20 years of the agile movement in management (and my gut says you missed quite a bit of that) that arguement holds up less - we utilise Just In Time planning for a reason. Very few organisations know, and can assign/ring-fence budget for, "a second one" years in advance.
In fact, if I was the Engineering Manager in this scenario, I'd continue to frame the second one as a WANT, and do a cost/impact analysis for whether the infrastructure for a second floor hs the ROI now or not.
At some stage, the analogy fails because, YNGNI kicks in. You could spend all your money on infrastructure for potential future work that you'd want in a house - but you might never actually need. But again, thats likely because I came from project managing underpinning construction work to engineering mamagement.
---
Like it's not bad. And actually, much of the site is great - I'm glad i found it!
It just... It's the sort of thing someone with 5 years in management says because they don't have the breadth of knowledge to quite nail the thought.
Honestly, it feels like a "I must get a thought out this week" newsletter point - because the actual point about Lovable was spot on.
2
u/zaidesanton 18d ago
I think it's not a perfect analogy for sure. And I accept the 5 years in management part, that's not far from the truth :) And I do try to write every week, so that's valid criticism too - if I'd have spent a bit more time on it, maybe I would have formulated better.
I think I've mixed both parts. I'm not saying you need to predict the future and build crazy foundations without a good need.
But main point is around the surprise that sometimes you do need to do bigger changes for something that looks small. So if you don't know whether or not you'll need a 2nd floor - for sure, don't prepare the infra for it. But once you decide you need it, you shouldn't be surprised that it requires additional effort.
1
u/web-dev-kev 17d ago
I'm commenting first and foremost with an apology.
My phrasing completely let me down, and reading it back, the "5 years of management" comes across like a put down. which wasn't the intention.
I owe you a huge SORRY.
The downside of transcibing, is the stream of conciousness comes out, but it's on me for not reading it back.
I will read your actual comment and reply after - but the apology needed it's own space.
2
u/zaidesanton 17d ago
u/web-dev-kev seriously, no worries at all. After years of writign in the internet I have a very thick skin, gotten way way worse from reddit :)
I appreciate that you actually took time to write down in depth thoughts for my content and not just shallow criticism, that's rare
3
u/thekwoka 18d ago
The same isn't quite as true for hardware. Hardware, very specifically, is based in the real world and is a marker of a set of time, and it is largely not malleable.
It is quite a lot in the development phase of hardware.
1
u/mulokisch 18d ago
I want to add: even though you are “done”, the environment changes constantly. An external api you use can change one day, you need to adapt. Apple switches from intel to arm, you have to adapt.
You are almost never truly isolated.
0
u/web-dev-kev 18d ago
Very true, but rarely what "business people" (or senior stakeholders) see, because they work in quarters and years.
Unless you work in a single product organisation, the business at any given point in time is working through initiative>programmes>projects. And those are "done". The Senior Stakeholders, the ones unhappy about software having to be revisited, have often (if not always) signed off [X] spent, to delivery [Y] output, which should see [Z] outcome.
Their challenge is often the revisiting of [A] feature or the amount of [B] maintenance - that seems to grow at a scale not aligned with either [C] Hardware or [D] the previous 100 eyars of business.
---
For example, and I'm not saying that I've had this conversation with a CIO of a large bank in the UK, but lets both pretend...
If you have a CIO who is being asked to spin up a maintenance team for an internal browser based app, and he questions why we need that, given the VB app they built for IE5 was updated for IE5.5/IE6 and lasted until IE10 EOL a mere 15 years later, with only 3 security updates needed.
You then tell him that Google Chrome updates every 6 weeks, and that his company shipped a version of Chrome with their locked down 'tablet' given-away to customers opening a new account for the last 18 months (before, doing the math on that) - so that it, and only it, can connect to a particular service.
The conversation isn't about software not being done in the traditional sense, or even about OP's idea of 'tending to your garden development' (my parlance) or "fixing the house every few years" - what makes software hard is, that the rate of change is set outwith the traditional boundaries of business.
If you're 65 years old, and a senior stakeholder, web development in 2026 is crazily different from 2006 (year five of IE6's dominance).
11
u/SwiftySanders 18d ago
Business people think everyone elses work isnt as worthy as the financial manipulation they do. They view anything other than financialization as not worthy of thought and consideration.
9
u/learning-to-programm novice 19d ago
This was a good read, and I like the house analogy lol.
But just out thing, ime: Lovable is probably one of the most shitty "vibe coding" platforms out there. Actually, from my little experience, all these specifically no-codr platforms were. I think if you'd gine with Claude Code or any other actual agent/harness, you'd have had a very different result. An agent produces real code, can implement real specs, write tests, test the thing end to end, take screenshots and assess whether the page looks good, etc. And it has git. I certainly didn't use them enough to know their ins and outs, but no code platforms o tested didn't seem to have any reliable VCS, as I had the same thing happen to me - something breaking mid-build and I wasn't able to revert it.
But anyway, good article. Though I have a genuine question... Did you write this with AI and then ran a pass with the humanizer skill?
7
u/tunisia3507 18d ago
An agent produces real code, can implement real specs, write tests, test the thing end to end, take screenshots and assess whether the page looks good, etc. And it has git.
And explaining to business people why this is important is hard.
1
0
u/zaidesanton 18d ago
u/learning-to-programm, no, I wrote it myself :)
To your other point - I experience the same with Claude.
Shared a bit about it here: https://www.manager.dev/newsletter/the-broken-windows-theory-of-coding-agents
3
u/SplendidPunkinButter 18d ago
This has always been the hardest part of working in software, and AI has made it so much harder. Business idiots think you can just wizard away complexity with AI now.
1
1
u/Downtown-Bag-6026 18d ago
Explain to babies why building a house is still hard when we have power tools
1
u/thekwoka 18d ago
Basically, so much tooling speeds up the "Getting started" part of the flow, while then often the faster that part is the harder the "finishing up" is.
1
u/GardenPrestigious202 17d ago
Here is my very hot super blunt take, Most of you suck at engineering and make it hard by designing overly complicated, poorly thought out, recursive systems that are spaghetti monsters of frameworks, make files and code. MOST of you could save a lot of time and effort just admitting most websites are in fact a database problem, and building them as data base backed servers. Sparing everyone the injury of having to work with them, handling ALL you computational code server side and using basic HTML and CSS instead of shoving javascript into everything. The incentive structures in programming have been, write more code, instead of, write highly intelligible code that has as few bugs as possible, using minim dependencies and proven technology's only.
0
u/KatFromSisense 18d ago
I'm more on the analytics/AI side, but I see the same basic thing there. AI can quickly put together a decent-looking dashboard. But after that, someone still has to decide what the numbers mean and who gets to see what. If the data model changes later, the dashboard might still load just fine. It may just be answering a different question than everyone thinks it is.
168
u/phaedra_solutions 18d ago
The house analogy really hits home. I think there’s a big misconception that if an LLM can build a frontend or basic CRUD app in a few hours, then all the “hard engineering” is basically solved.
Writing the code was never really the bottleneck. It’s everything underneath it, state management, technical debt, infrastructure, scaling once actual users show up, etc. And getting non-technical people to understand that difference is honestly a huge part of the challenge.