Explaining to business people why building software is still hard

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. As soon as I fix one problem, another one appears, and our app is barely usable.

The start was very promising. I joined 2 engineering friends and 3 recruiters to build ‘HoneyCrew’, a smart referral system (the goal was to send a weekly summary to every employee with potential candidates from their network for our open roles. Here’s an open source version). We decided to go with Lovable so the recruiting team can maintain it themselves later.

On the first day, we just FLEW, completing 90% of the project. Scraping, scoring, Slack integration, admin - things looked almost ready.

On the 2nd (and final) day, we worked on some minor improvements, and things just… Completely broke. Endless bugs everywhere, slowness, everyone super stressed.

The recruiters on our team couldn’t understand what went wrong. We were on the path for an amazing product, and now we were in danger of not having anything ready for the demo.

How come?

I used to work with a senior leader who loved to say that he has an allergy to the words ‘refactor’ and ‘infra work’. He couldn’t understand why we couldn't build it right from the beginning, and why we were always so slow. After LLMs appeared, it became even worse. He constantly asked: “Can’t you just give this task to ChatGPT? What’s the problem?”

To his credit, he at least asked this to our faces. I know many non-technical leaders who think engineers always exaggerate and work too slowly. It’s a flavor of the same old software engineering war I talked about last week.

A coworker (and a good friend) once framed it like this: “You write code, which is just words in a language I don’t understand, right? With fixed meaning. And you know what you want to say, as you have the specs you need to follow. How come it always gets more complicated?”

Huh.

I’ve been struggling to explain this, until I almost bought a house:

Last October, we saw a house for sale near my parents-in-law. It looked like a great deal - good location, nice neighbors, a garden like we wanted, and very affordable. It was small and 30 years old, but the low price left us extra to spend on it.

So we asked a contractor: “How much would it cost to renovate it and expand by 2 additional rooms?”

I couldn’t stop laughing at his response:
“I wouldn’t recommend it. It’s too old. It’d be much simpler and cheaper to destroy it and build from scratch”.

He could have been a great software engineer…

We passed on it, but since then I’ve been using the house analogy quite a lot when talking about software.

The house-building process has been known for thousands of years, and still every new one has different problems. And everyone lives in one, so it feels relatable. For example:

Your roof leaks. You can either put a bucket on the floor, or find the root cause. If it’s your own home, what would you do?

Yeah, a bucket might be ok for a couple of days, but you need to constantly empty it, and you risk the real issue becoming worse.

Let’s say you build a new house for your family. 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.

So it’s 1 pm on the final hackathon day, and everything feels broken.

We didn’t really have any other choice. We stopped our vibe coding frenzy and carefully went over one area at a time until we had a simple demo-able flow working. Understand, plan, implement. Much slower than our day-1 pace, but we at least ended up with a working demo-able flow.

This process is how good software is built, but it gets so easily forgotten, just rushing forward. And unlike a house, you never really finish building it, so you constantly need to update the facilities while people already live inside.