31 Improve the development process itself

A development method is also a system. It has users, interfaces, state, costs, and failure modes. It can accumulate compatibility layers, stale assumptions, and rituals that no longer serve their original purpose.

If the method advocates proportionality, it must apply that principle to itself.

A process can be too rigorous in the wrong way

The inspected Planning Proportionality Recovery records describe a correction to an overgeneralized planning architecture. Generic transition and digest machinery had been applied too broadly. The repair restricted stale-state controls to work where independently prepared proposals could become outdated before integration. Multiple participants alone no longer implied that risk.

A recorded read-only pilot prepared a temporary 132-line Pantograph plan and checked its structure and links while avoiding changes to a checkout with unrelated dirty documents. It did not implement the proposed product change. The case shows an accepted policy correction and bounded pilot, not a measured productivity improvement. Recovery plan; pilot report.

This is more instructive than a rule to always use a plan. The method recognized that a specialized safeguard was imposing obligations on tasks without the relevant hazard. It preserved scope, ownership, and acceptance while reducing unnecessary machinery.

Identify the cost before adding a rule

A new rule often follows a real failure. An agent used stale context, omitted a test, or changed a shared file without coordination. The natural response is to require another check everywhere.

Before doing that, identify the conditions that made the failure possible. Does the risk apply to every task, or only to a particular concurrency pattern? Can the owner enforce it once instead of every caller documenting it? Is the new requirement likely to prevent the failure, or merely record that someone considered it?

A safeguard can be valuable and still need a narrower trigger. It can also create new failure modes: blocked work, confusing authority, duplicated records, or false declarations of uncertainty. The Passeur proof-boundary case discussed in the coordination chapters illustrates why demanding more evidence is not automatically the correct contract.

Distinguish compliance from effectiveness

A workflow can be followed perfectly and produce a poor result. A developer can omit a prescribed artifact and still make a sound decision. Neither observation alone settles whether the workflow is useful.

Compliance tells you whether the process occurred. Effectiveness asks whether it improved an outcome relative to a relevant alternative. The latter requires a comparison and careful attention to task differences.

Choose a bounded improvement to investigate. Perhaps targeted guidance could replace a broad instruction dump. Perhaps a small serial task can omit a coordination record. Perhaps a runtime demonstration catches errors missed by the current tests. Define the outcome and the cost you will observe before changing the process.

Boehm's risk-driven account treats both insufficient exploration and excessive exploration as risks, and scales effort and artifact detail to what a decision needs. It provides a useful conceptual basis for this work, without a universal formula for the optimal stopping point. Spiral Development Experience Principles and Refinements.

Make criticism actionable

Puma wants criticism to be one purpose of this book. The following questions are proposed prompts for that criticism, not invented statements about what Puma must believe:

Where does the approach mistake a well-kept record for actual understanding?
Which improvements may depend more on domain familiarity or model capability than on the method?
Where would a direct implementation followed by user feedback be cheaper and equally dependable?
Which important work is missing because it is difficult to represent or measure?
Do the cases include enough rejected alternatives and adverse outcomes to judge the decisions?
What can another developer reproduce, and what depends on individual judgment?

A useful response identifies the claim being challenged and a condition or example that changes it. “This is too much process” becomes more actionable when it names the task class, the unnecessary obligation, and the simpler alternative. “This needs more rigor” becomes more useful when it identifies the failure the current evidence cannot exclude.

Keep the method open without making every task a referendum

Not every implementation should reopen the entire engineering philosophy. Stable guidance reduces repeated decision cost. The method needs a way to distinguish a local exception from evidence that a rule is wrong or mis-scoped.

Record recurring friction. Look for patterns across tasks rather than treating one inconvenience as a universal defect. At the same time, do not require repeated harm before correcting a clear contradiction or dangerous boundary.

The approach developed in this book is a set of relationships to preserve: purpose to behavior, concepts to invariants, authority to action, and claims to evidence. Its artifacts are means of preserving those relationships. Their form can change when a simpler or more effective method becomes available.

That is the position readers are invited to examine. The work is not complete because the process has a name, the graph is connected, or the tests are green. It becomes useful when another person can understand what was intended, inspect what happened, judge what the evidence supports, and decide what to do next.