The Cognitive Cost of Cleverness: Why "Boring" Technology is Usually the Right Choice

For years I had the same thing happen and couldn't explain it honestly. The clever design, the one I was a little proud of in review, the one that used the better-fitting tool, turned out six months later to be the part of the system nobody wanted to touch. The boring alternative I'd talked myself out of would have been fine. Not the dumb move going wrong. The smart one. I sat with that gap for a long time, and the answer came from a bolt.

When I was certifying on the 737 I spent time safety-wiring fasteners. You torque a bolt to spec, then run a thin steel wire through a hole in its head and anchor it so the wire pulls against loosening. It is slow. It looks primitive next to a self-locking fastener that needs none of it. Boeing uses the wire anyway, in places that matter, because of what happens after I leave. The next mechanic, in dim light on a cold ramp, can see in one glance whether the wire is intact. The locking feature buried inside a clever fastener tells him nothing from outside. The boring method moved the cost to where it was cheap to pay: the moment of inspection, by someone who is not me and was not there.

That is what I'd been getting wrong about clever code. I was pricing the writing and ignoring the reading.

A clever design costs almost nothing to write. The cost shows up later, spread thin across everyone who has to load it back into their head to change one line. I felt smart writing it. The tax gets paid by whoever opens the file next, including me eight months on with no memory of why the trick was necessary.

The clearest case I have is a job queue. We needed background work processed reliably, with retries and ordering, a few thousand tasks an hour. The clever answer was a real message broker. Partitions, consumer groups, exactly-once semantics, a tool built for precisely this. I almost reached for it. Instead we put the jobs in a Postgres table the application already used, with a status column and a worker that claimed rows with SELECT ... FOR UPDATE SKIP LOCKED.

A broker is the right tool. The table is not. But the table fit inside what the whole team already understood. No new thing to run, no new failure mode to learn, no second system to page someone about at 3am. When a job got stuck, you queried a table. Every engineer could read that, the way the next mechanic could read the wire. The broker would have been faster and would have isolated the queue from the database. It also would have been one thing one person understood and four people quietly feared.

The clever choice still has its place. Throughput the table genuinely can't carry, ordering a status column can't guarantee, volume that breaks the simple thing for real. Those are when the broker earns its weight. They show up less often than they feel like they will in the moment.

What changed is small and specific. Before I pick the better-fitting tool, I write down who reads this next and what they can verify without me in the room. If the boring version is something they can inspect at a glance, the way you can see whether the wire is intact, that is where I land now. I stopped logging the difference as something given up.