Problem-shaped software

A pattern earns its keep by being cheaper to apply than to argue about. This one has survived insurance claims and four other sectors that share none of the same vocabulary, which usually means the shape is real and not a coincidence.

Most software people hate is software that was shaped by its tooling rather than by the job. The order matters more than the technology: understand the work, then build the thing that fits it. Reverse that and you get a system everyone has to be trained to tolerate.

THE WORK COMES FIRST

There's a moment in most projects where someone reaches for a product name before anyone has described the problem in a full sentence. It feels like progress. It's the opposite. Once a tool is in the room, the conversation quietly changes from what needs to happen into what that tool can be made to do, and nobody notices the substitution.

We try to hold off naming anything for the first week. Not out of purity. It's just that the constraints you discover in week one are the ones that decide the architecture, and you can't discover them while defending a choice you've already made.

HOW YOU KNOW IT FITS

A system that fits the work has a particular feel. The words on screen are the words people already use out loud. The states a record can be in match the states it's actually in. Nothing important lives in a comment field. When someone new joins, you explain the domain, not the software.

The tell for a bad fit is the shadow system. Every place we've worked that ran on software shaped by its tooling had a spreadsheet next to it, and the spreadsheet was where the real decisions got made. It's the most reliable diagnostic we know, and it takes ten seconds to run: ask what they keep outside the system, and why.

It paid for itself the first time a reserve was released twice against the same loss. Because the structure was already there, recovery was a query instead of an investigation, and adjusters heard it from the system rather than from a customer.

THE COST OF THE WRONG SHAPE

Wrong-shaped software isn't usually slow or buggy. It's just permanently a little bit wrong, in a way that costs everyone twenty minutes a day and never rises to the level of a ticket. That's the expensive kind. A crash gets fixed. A daily twenty minutes gets absorbed into the job description.

It also compounds. Each workaround becomes something the next feature has to be compatible with, and after a few years the workarounds are load-bearing. By then the honest option is a rebuild, which is a much harder conversation than the one nobody wanted to have at the start.

At a specialty claims administrator it turned a recurring escalation into an ordinary state the system could describe. About 15,000 claims a month went through without a single manual reconciliation, which hadn't been true of any quarter before it.

WHERE IT GOES WRONG

• Naming things after the vendor's vocabulary instead of the client's, so every conversation needs a translation step.
• Treating the spreadsheet people already use as a symptom to be eliminated rather than a specification to be read.
• Shipping a system that works perfectly on the happy path, which turns out to be nineteen percent of cases.
• Picking the platform in the first meeting, then discovering the constraint that rules it out in week five.

Build around the problem first. Then build the system that fits it.

WHEN TO REACH FOR IT

It's cheap on day one and expensive to retrofit, which makes it a default rather than a decision. We put it in the first commit and haven't regretted it yet.