Patch one leak in an old pipe and the pressure goes looking for the next hole.
A team’s release process is painful. Deploys take a day, something breaks every third release, and everyone agrees it needs fixing. So someone volunteers to make the build faster, and after a month of good work the build is faster and releases are just as painful. The effort was fine; the diagnosis was missing. The first step in solving any problem is identifying what kind of problem it is, because the structure determines which interventions work, which are wasted, and which make things worse.
Spencer Greenberg’s problem taxonomy names nearly thirty such structures, and its value is the habit it trains. Run the release problem through a handful of them and the same symptoms point to very different work.
Same symptoms, different shapes
Perhaps it is a Shark Laser: the proposed solution is not aimed at a meaningfully important problem, so it does not matter how well you get it to work. The faster build was a shark laser if the pain came from what was being released rather than how. The engineering algorithm asks whether a step should exist before optimizing it.
Perhaps it is a Smashed Watch: so many issues at once that fixing one has no benefit unless you fix the others too. If flaky tests, manual approvals and an undocumented config each break releases on their own, repairing any one leaves the outcome unchanged.
Perhaps it is a Leaky Pipe, where fixing one problem intensifies others: speed up deploys and more changes ship each week, putting more pressure on the flaky tests. Or the slow manual approval is a Chesterton’s Fence, put there on purpose as the solution to a now-invisible problem. Before deleting it, find out what it was guarding.
Or it is a Middle Court Shot, easy to solve but falling between several teams’ responsibilities, so nobody owns it. Or a Loose Thread, easy to fix early but too minor to bother with until it is costly. Technical debt is the classic loose thread, and release processes usually turn painful one ignored annoyance at a time.
The name is a hypothesis
Each diagnosis implies different work: delete, coordinate, investigate, assign an owner, or pay down early. That is why naming the structure is half the solution. The other half is remembering that the name is a hypothesis. A team can call its problem a Lead to Gold problem, too hard for anyone to solve, when it is really a Booby Trapped Garden: hard for reasons not apparent from outside, so each new attempt underestimates it.
The month spent on the build was not wasted if it ruled out one shape. The harder question is how many of your own standing problems you have tried to solve many times and never once tried to classify.
References:
- Spencer Greenberg, Problem Taxonomy