Building Castles in the Sand

We don’t need faster shovels. We need to remember why we started building.

Ever since I was young, I wanted to transform unstructured data into actionable business insights.

That line, that meme, it’s a joke, but it’s where most of us end up. Building software that we’ll never use, not our own dreams, not for software we wish existed. Instead products born from requirements documents, not from genuine need. Roadmaps shaped from slide decks, not for hands-on keyboard.

When you’re not the user, the feedback loop breaks; success is measured in adoption metrics, training sessions, and compliance audits. Not from or with love, not from daily use.

Even worse than you not using it, it’s not even directed and informed by the end user; there’s usually a committee or management sandwiched in between requesting dashboards, but never actually logging in.

This is where most of us find ourselves building enterprise software; it’s why it mostly sucks. It looks grand from a distance, towers, turrets, walls, they’re all there, but they’re built on nothing, and when the tide comes in, and it always does, the castle washes away.

Compressing Complexity OR Expanding It

Now, there’s a new kid on the block—LLMs, without doubt, they’ve accelerated the surface-level work. Still, I’m already building software twice removed from the source: User → [committee] → Analyst → Developer. Now, I’m a step further removed from the raw materials of my craft.

Choose your poison: Anthropic, OpenAI, Droid, Aider…

I’ve found myself using them to great effect, scaffolding front-end UIs, reasoning through bugs, and pairing on problems. But when we start on the path of more expansive programs of work, when I come to expect too much (or become too lazy), and it drifts into confusion, I’m so far removed it’s a long way to chase it down the rabbit hole. The code works, but I’ve lost the thread, and I don’t know which end to pull from.

This feels like avoidable incidental complexity —the kind we create for ourselves, an extra layer that traps us in the middle. It’s far from being beautifully simple, for that requires intimacy with the code and the problem. If I’m not building software that I understand or use, then what am I doing?

Built to Last

The things that last are the things we build for ourselves first.

• Rails wasn’t born from a market survey; DHH extracted it with care and attention from a product. A set of opinions about how to build software rolled into a beautifully successful framework.
• Unix wasn’t born from committee; Ken Thompson built it so he could play his games.
• Rich Hickey created Clojure because everything else felt too complex, too compromised.

When you build for yourself, you can taste when it’s good. When you live in it, you know it’s honest.

Software born from irritation. An itch that won’t leave you alone until you scratch it. It’s time to stop stacking turrets, building from borrowed requirements.

Better a shack that you live in than a fortress no one will ever use.