Explaining to business people why building software is still hard

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.

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

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.

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

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

Pretty much every project. Initially your pace is great. You're knocking out features quickly. Everyone is upbeat and enthusiastic. Then you have to put it all together. You discover scenarios that the specs don't cover. You need more info from business about validating certain combinations of inputs. When you get that, you find contradictions with some other stuff you thought was already done. You need to store another field that they forgot about, or thought was just common knowledge. So now you need to alter the database. Combinatorial complexity. It's the essential problem with software systems. If business people don't understand it, tell them to read Brooks. If they still don't understand, tell them to read it again.

> "Never really finish building it" is the key insight.

The problem with software is that it is never done. There is always another feature you could have and worse than building a property the work is only done by the people on the outside.

I don't know that saying "this work is hard" is enlightening.

More useful would be to be able to explain at some high level what the the inherent and accidental complexity is, the tradeoffs to navigate, long-term vs short-term decisions, etc.

Saying "it is hard" makes the audience think you're less of an expert in your domain and they are then inclined to find someone who doesn't say "this work is hard".

We’re in the self driving car stage right now. A Waymo can drive itself but the belts and suspenders involved are more expensive than a normal car.

This is definitely getting my favorite. I’m also going to shamelessly steal this house analogy.

Thanks for writing this!

Medical doctors mostly follow standard procedure and decision trees.

TBH I think we still need to explain this to ourselves first.

My experience over many decades is this:

* If a business person thinks a change or new program is very easy to do, it is really a very hard project.

* If a business person thinks the change or new program us hard to do, usually it is a trivial project.

For me, this has been true for well over 40 years. I never use any kind AI for my work, it did not exist before I retired.

It's the rest of the owl.

>We decided to go with Lovable so the recruiting team can maintain it themselves later.

Yeah, I'm not sure that's a good idea. At the end of the day, Lovable is still a TypeScript web-app with a Supabase backend full stack system. If you don't understand what you have the LLMs actually build, then there is no way you can maintain it or debug it if something goes wrong.

All these no code/vibe code website generators don't make the code go away; the code maintenance burden just shifted to somebody else.

To me stories like this seem like just a moment in time.

Like in 1 to 5 years, vibe coding without looking at the code will likely be a lot better.