Why building software is still hard: a house-building analogy
Explaining to business people why building software is still hard
A hackathon team using Lovable raced to 90% completion on day one, then hit a wall of bugs and slowness on day two. The author, a manager, uses a house renovation analogy to explain to non-technical leaders why software can't be built perfectly from the start, why 'infra work' matters, and why you never truly finish building. The lesson: slow down, understand, plan, implement.
It’s 1 pm on the final day of the Hackathon, 5 hours left. For the last 2 hours, we made ZERO progress. I’m cursing the day Lovable was born.
- dasil003
All software is path dependent, all code is a liability, and all technical decisions are tradeoffs. These are the immutable truths of software that not changed one iota due to AI or any Moore's Law progress before it.
There are too many product managers and decision makers that are unable or unwilling to do the hard work of actually thinking through what they want, and re-evaluating their priors as new feedback and learnings come in. Similarly, there are too many engineers who are distant from the customer and the problem at hand, and end up chasing their own idea platonic ideal of good software, detached from the hard tradeoffs of what is truly needed right now vs what we anticipate needing in the future. The less software we can write to solve the problem now, while minimizing one way door decisions, and deferring as many "scaling" challenges as long as possible to make decisions with more complete information the better.
This is why AGI won't magically solve software development—because people don't actually know what they want until they try it and then they want something else. Raw intelligence can not solve for purpose or human goals. The better it gets, the more it will become like an evil genie or monkey's paw that never quite does what the feeble-minded human prompters want.
- tripleee
This is all caused because no-one understands the purpose of quality in software
Low quality = cascading bugs, issues, slow to iterate and add or change features
This is just as true for human written as it is for AI
Instead we have everyone giving up on code quality as if it was just "beautiful code" perfectly indented that was only there for people to ooh and aah at
- miranaproarrow
My manager who vibe coded our entire webapp in claude design. Has difficulty understanding why its still not production ready.
My job is to wire to our backend data, and a lot of these wiring require me to be in there and actually think about the features. These take time, and I just haven't figure out a way to speed this process up with Claude.
- digitallogic
> 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.
The problem with this thinking is it requires certainty about the future. It's much cheaper right now IF AND ONLY IF you end up needing the thing. If you don't need it, then you've threw time and money down the drain.
Where I think this analogy weakens is you probably have far more certainty of whether or not you want a big family then you do on whether or not a new product line will see major adoption.
- mehagar
Even if you do use AI tools to help you write the code, at some level you have to specify what the program's output should be for every possible input.
By loosely specifying things in a prompt, there's simply not enough context for the AI tool to know the "right" output to produce for all possible inputs. What's "right" is often subjective anyway ("Should this button be red or blue?").