Start from the problem, not the spec

A specification is an answer wearing the clothes of a question. By the time a requirement reaches an engineer as “build X,” someone has already decided that X is the thing to build. Often they are right. Often enough that it is worth checking, they are not — and the cost of not checking lands much later, when X is built correctly and still does not solve the problem.

Lately the industry’s answer to this has been to write better specifications. Code generation has become fluent enough that an entire discipline — spec-driven development — has grown up around making the spec the source of truth, the thing that keeps a confident model from producing something plausible and wrong. It is good advice, and it stops one step short. A specification precise enough to eliminate every ambiguity can still describe the wrong problem — and no amount of precision downstream will recover from that.

I spent enough years in business analysis and solution design before I led engineering that I find it hard to switch the habit off. When a spec arrives, I read it as a hypothesis about the solution, and then I go looking for the problem it claims to address.

The gap between spec and problem

The gap is usually not incompetence. It is compression. A real situation — messy, full of exceptions, shaped by how people actually work — gets compressed into a tidy requirement, and the compression quietly discards the parts that were hardest to express. Those discarded parts are frequently the ones that determine whether the solution works.

So before shaping anything, I try to recover what was compressed away:

• What does success actually look like for the person on the other end?
• What happens today when this goes wrong, and how often is “wrong” the normal case?
• Which constraints are real, and which are habits that have hardened into assumed constraints?

These are not technical questions, and that is the point. The best structural decision in the world cannot rescue a solution aimed at the wrong target.

Why engineers have to engage

There is a tidy division of labour where someone else figures out what and engineering figures out how. Where those roles exist they earn their place — a good analyst does work engineers rarely have the proximity or time to do well. But the line between the two is never as clean as the org chart suggests. The shape of the right solution and the shape of the right implementation inform each other, which means engineers can’t treat the what as settled and none of their concern. A problem understood properly often dissolves half the complexity the spec implied, because the spec was carrying assumptions the problem never required.

Shaping the right solution before a line of code is written is not a separate phase. It is the part of engineering that determines whether the rest of it was worth doing.

The work that lasts tends to come from starting one step further back than you were asked to. Not building the spec — building the thing the spec was reaching for.