Complexity Budget Review¶
Governance review — instantiates Second-System Complexity Restraint
A recurring review that totals the successor's cumulative complexity against a fixed cap and flags when the sum — not any single item — starts to threaten launchability.
A successor rarely dies from one bad decision; it dies from a hundred locally reasonable ones. Complexity Budget Review is the recurring ritual that judges the aggregate. It fixes a complexity-and-scope budget up front — a cap across feature count, configuration surface, integration load, architectural generality, operational burden, and user learning load — and then, on a cadence, sums the successor as it actually stands and compares the total against the cap. Its defining idea is that no item is evaluated on its own merits here; each addition was probably fine alone, and the review exists precisely to catch what item-level approval cannot see: the point at which the pile, however reasonable piece by piece, has grown too heavy to launch.
Example¶
A consumer video-streaming service is rebuilding the client-side player that its first app shipped in a lean, single-codec form. The successor's backlog is full of individually sensible additions: adaptive bitrate, offline download, picture-in-picture, watch-party sync, a plugin API for partners. At kickoff the team set a budget — a ceiling on codecs supported at launch, on user-facing settings, on background services the device must run. Every three weeks the Complexity Budget Review re-totals what has actually been merged and pending against those ceilings.
At the fourth review the settings count has quietly crept past its ceiling and background services are two over budget; the player still works in the demo, but QA cycle time has doubled and the low-end-device target is slipping. The review does not debate whether watch-party sync is a good feature — it is — but reports that the sum now endangers the launch on the promised devices. That verdict forces a choice the per-item process never would: cut, defer, or formally raise the budget with eyes open. The team defers the plugin API to a later tier and relands the low-end target.
How it works¶
- Set the budget as a vector, not a number. Cap each dimension of burden separately (features, config, integrations, generality, ops, learning), because they trade off against each other and a single scalar hides which one is blowing.
- Re-measure the actual successor on a cadence. At each review, total what is merged plus committed, not what was planned — drift lives in the gap between the two.
- Judge the aggregate against launchability. The question is never "is this item worth it" but "can the successor still be built, migrated, supported, and learned at this total?" — a running launchability check, not a milestone gate.
- Force an explicit response on breach. A dimension over cap must be resolved by cutting, deferring, or a recorded, authorized budget increase — never by silent acceptance.
Tuning parameters¶
- Budget dimensions and caps — which burdens are metered and how tight each ceiling is. Tighter caps protect launch but can starve genuinely needed capability; the caps encode the team's real risk tolerance.
- Review cadence — weekly, per-sprint, per-milestone. Frequent reviews catch drift early but cost attention; sparse ones let the pile grow past recovery between checks.
- Measurement rigor — eyeballed estimates versus instrumented metrics (build time, config keys, service count). Harder numbers resist optimism but cost tooling.
- Breach response threshold — how far over cap triggers mandatory action versus a warning. A hair-trigger creates churn; a loose one lets the budget become decorative.
When it helps, and when it misleads¶
Its strength is seeing the accumulation no item-level gate can: it makes the conservation of complexity visible and assigns the total a keeper, so a successor cannot become unlaunchable one reasonable addition at a time.[n1] Because it judges the sum on a cadence, it also converts "we'll worry about scope later" into a scheduled, unavoidable reckoning.
Its failure mode is metric gaming and false comfort: a budget expressed in countable units (features, config keys) can be satisfied while real complexity hides in coupling and interactions the metrics miss, so a green review is not proof of a launchable system. The classic misuse is letting the budget become a ceremony that is quietly raised whenever it binds — at which point it measures ambition rather than restraining it. The guarding discipline is to keep at least one dimension anchored to an outcome that cannot be gamed (does the low-end device still hit its target?), and to require that every budget increase be authorized and recorded, not absorbed.
How it implements the components¶
complexity_and_scope_budget— the review is the budget's enforcement loop: it defines the multi-dimensional cap and re-scores the successor against it.launchability_review_cadence— the recurring aggregate check is the launchability cadence, testing whether the cumulative burden still leaves the successor buildable, migratable, supportable, and learnable.
It does not price a single architectural option's future cost — that per-decision artifact is Architecture Decision Record with Future-Option Cost; and it does not enforce successor_core_contract parity before expansion — that sequencing precondition is the Parity-Then-Expansion Gate.
Related¶
- Instantiates: Second-System Complexity Restraint — supplies the aggregate-burden guard that protects launchability across the whole successor.
- Sibling mechanisms: Architecture Decision Record with Future-Option Cost · Constraint-Release Inventory · Feature Admission Rubric · Parity-Then-Expansion Gate · Postlaunch Ambition-Thaw Review · Rewrite Scope Firewall · Second-System Premortem · Staged Release Ladder · Successor Charter
- Compare: Complexity Budget Gate — the separating dimension is what gets judged: the review judges the cumulative total on a cadence (no item judged alone), whereas the gate prices each new addition at the door.
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: A recurring review that totals the successor's cumulative complexity against a fixed cap and flags when the sum — not any single item — starts to threaten launchability, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Complexity Budget Review as 'A recurring review that totals the successor's cumulative complexity against a fixed cap and flags when the sum — not any single item — starts to threaten launchability', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Systems engineering established allocated technical margins and recurring performance measures that compare current cumulative requirements, interfaces, resource consumption, and deviations against anticipated ranges and trigger corrective action when launch requirements are threatened.
Related originating lineages:
- Human-Computer Interaction — Human-centered design contributes the user-learning and interaction-burden dimensions and the conservation-of-complexity warning.
- Organizational & Management Science — Portfolio governance supplies recurring aggregate review, ownership, authorization, scope tradeoffs, exceptions, and explicit cut-or-defer responses.
Review resolution: NASA's Systems Engineering Handbook defines allocated margins and technical performance measures, including trends in requirements, interfaces, deviations, and release contents, that are monitored against expected ranges to identify jeopardized system requirements. PMI portfolio practice adds periodic review of scope, dependencies, resource and capacity constraints with authority to continue, defer, or terminate components. The mechanism synthesizes those traditions into a complexity-specific cumulative budget review.
Attribution caveat: Portfolio governance supplies the review ritual and HCI supplies user burden, but engineering design is primary because the reviewed object is the successor system's aggregate technical launchability across coupled constraints.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- NASA: Systems Engineering Handbook—Technical Performance Measures and Margins
- PMI: The Standard for Portfolio Management—Portfolio Reporting and Review
Notes¶
[n1] Tesler's Law, or the conservation of complexity — the principle (attributed to Larry Tesler) that a system has an irreducible amount of complexity that can be moved around but not removed; if features keep being added, the total complexity someone must carry keeps rising. A budget review is the mechanism that makes that rising total visible and caps it. ↩