Tool 15 of 32 · about an hour
Compounding Check
Is the mess growing faster than the patching, or is patching still keeping pace?
Second check in the Depth working session, read from artifacts, never from vibes.
What it is for
To see whether complexity in the traced area is now growing faster than the team can patch, so patching can stay a strategy or be taken off the table.
The failure it catches
Every patch adds hidden state: another branch, another exception, another special case, another assumption one person remembers. Complexity compounds. It does not add. When complication grows faster than resolution, patching that area is a treadmill that speeds up.
Why it works
Trends from the company's own artifacts, branch and special-case counts, regression frequency, QA cycle length, build or reprocess times, the count of we are close loops, show whether patching is keeping pace. Vibes about how it feels always lag the treadmill.
How to run it
- From the traced area's artifacts, not from how it feels, compare the rate at which complications are being added against the rate at which they get resolved.
- Look at branch and special-case counts now against a year ago, regression frequency, how long a build or QA cycle or reprocess takes, and how many times we are close has been said about this area, over how many months.
- Also watch whether three or more of these stand together: regressions rising, each fix touching more areas, people afraid to change the module, cycles expanding, we are close repeated monthly, bugs appearing in unrelated areas, feature velocity dropping, test combinations exceeding what can be covered, only one person still understanding the module.
- Write the reading before the next check.
How to read the result
When compounding outruns patching, patching that area is a treadmill that speeds up, and the honest options shrink to rebuilding or accepting decline. The Patch Validity Test is then suspended for that module: no further patches except true outage and safety work. When resolution keeps pace, patching remains a legitimate strategy. Where we set that line is our judgment, not proven science.
How to run it well
- Read the trend from artifacts, never from vibes.
- Outage and safety fixes always run. This check does not licence inaction.
Where it breaks
- It is all broken anyway as a licence for inaction is burnout talking, not this check. Outage and safety fixes always run.
- Quoting someone else's numeric markers at the room, instead of this company's own artifacts, turns a reading into theatre.
What would prove it wrong
A module past the compounding threshold that then absorbs further patches cheaply would mean the threshold is wrong.
What we watch
Whether areas that read compounding-outrunning-patching keep getting more expensive to touch, or whether some of them absorb further patches cheaply.
Ask yourself
- How many branches and special cases live in this area today, against a year ago?
- How long does a build, a QA cycle, or a reprocess take now, against then?
- How many times has we are close been said about this area, and over how many months?
- Is complication arriving faster than it is being resolved, or is patching still keeping pace?
Fed by: Convergence Test, Patch Validity Test
Feeds: Leverage Layer, Patch Validity Test