Interface Surface Reduction Review¶
Procedure — instantiates Essential-Accidental Complexity Triage
A review that trims exposed options, fields, APIs, or decision paths that do not correspond to essential problem distinctions.
Interface Surface Reduction Review works on one specific target: the exposed surface a system presents — its options, fields, settings, endpoints, and branching decision paths — hunting for the ones that do not map to any essential distinction and can be retired. Its defining move is to treat every element of the surface as a standing tax on whoever must read, choose, or integrate against it, then to justify each element's continued existence or schedule its removal. It is not a diagnosis of internal coupling and not a domain safety check; it is the working session that turns "this surface is bloated" into a concrete backlog of surface elements to cut, each priced by the burden removing it saves and each survivor carrying a reason to stay.
Example¶
A smart-thermostat's installer configuration screen has grown to sixty-three settings across nine menus, and field technicians routinely misconfigure units. An interface surface reduction review takes the screen element by element. The "compressor minimum run-time" field maps to a real HVAC-protection distinction — kept, with its rationale written down. But "display contrast," "legacy relay polarity," and eleven advanced-mode fields turn out to correspond to no distinction any current hardware makes; two of them duplicate settings the app already infers automatically. The review scores each candidate by the burden its presence imposes — how often technicians touch it, how often they get it wrong, how many support calls it generates — and produces a ranked cut list: retire the eleven dead advanced fields (high misconfiguration cost, zero payoff to keeping), fold two into auto-detection, and keep but relabel the polarity setting because a small installed base still needs it, recording exactly why. The screen drops to twenty-nine settings, and each survivor now has a written reason it earned its slot.
How it works¶
- Enumerate the surface. List every exposed option, field, endpoint, and decision branch — the review's unit of work is the surface element, not the internal module.
- Test each against essential distinctions. For every element, ask which real problem distinction it expresses; an element that maps to none is a removal candidate.
- Price the removal. Score each candidate by the burden its presence imposes (choices forced, errors induced, integration cost), producing a ranked backlog rather than an undifferentiated list.
- Justify the survivors. Every element that stays gets a short recorded rationale, so the surviving surface is defended, not merely inherited.
Tuning parameters¶
- Surface scope — user-facing options only, or public APIs and internal decision paths too; wider scope finds more waste but risks touching contracts external parties depend on.
- Removal aggressiveness — deprecate-and-watch versus cut-now; aggressive cuts realize savings faster but raise the chance of breaking a quiet real dependency.
- Payoff metric — which burden the ranking optimizes (user error rate, support load, integration effort); the chosen metric decides which elements rise to the top of the cut list.
- Grandfathering policy — whether existing users of a doomed element are migrated, frozen, or dropped; generous grandfathering is safe but leaves residual surface behind.
When it helps, and when it misleads¶
Its strength is directness: the exposed surface is where accidental complexity is most visible and most felt by outsiders, and a disciplined pass reliably converts a sprawling menu or a fifty-endpoint API into a lean, defended one — with the savings booked and every survivor justified. It is the mechanism that most quickly reduces the cognitive tax a system charges its users.
Its failure mode is the hazard that an exposed element with no obvious purpose may still have silent dependents: some integrator has wired against that odd field, and cutting it breaks them invisibly.[1] The classic misuse is optimizing for a clean-looking surface — trimming what is easy to remove rather than what is costly to keep, or hiding complexity behind a "simpler" default that merely relocates it. The guarding discipline is deprecate-and-observe before hard removal for anything with possible external consumers, and pairing each proposed cut with an informal check for live usage rather than assuming an unexplained element is dead.
How it implements the components¶
accidental_complexity_backlog— the ranked cut list of surface elements that map to no essential distinction is the backlog this review produces.removal_payoff_estimate— each candidate is scored by the burden its removal saves, so the backlog is prioritized by payoff, not convenience.residual_complexity_rationale— every element that survives the review leaves a recorded reason for staying, so the remaining surface is defended.
It does not run the cross-role attribution that decides which surface is accidental in the first place (approach_induced_burden_inventory, complexity_attribution_rubric, boundary_of_responsibility_map) — that is complexity_attribution_workshop; nor does it certify that a cut preserves domain invariants (irreducible_constraint_register, simplification_safety_gate) — that guard belongs to domain_invariant_review, its nearest procedure twin, which owns the constraints saying what may not be trimmed while this review trims the surface and books the savings.
Related¶
- Instantiates: Essential-Accidental Complexity Triage — this review is the archetype's surface-pruning arm, turning classified bloat into a priced cut list.
- Consumes: essential_accidental_complexity_audit — flags which surface elements are classified accidental; domain_invariant_review bounds what the trim must preserve.
- Sibling mechanisms: complexity_attribution_workshop · domain_invariant_review · dependency_simplification_map · legacy_constraint_map · refactoring_paydown_plan · complexity_budget_gate · residual_complexity_justification_template · simplification_regression_suite
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Interface Surface Reduction Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a review that trims exposed options, fields, APIs, or decision paths that do not correspond to essential problem distinctions
Independent corroboration: The frozen evidence defines Interface Surface Reduction Review as 'A review that trims exposed options, fields, APIs, or decision paths that do not correspond to essential problem distinctions', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Reducing exposed API surface while managing hidden dependencies is rooted in software architecture and compatibility engineering.
Related originating lineages:
- Human-Computer Interaction — Progressive disclosure and option simplification materially shape analogous reduction of user-facing fields and paths.
Review outcome: Independent reviewer agreement; high confidence.
References¶
[1] Wright, H. "Hyrum's Law" (n.d.). Hyrum's Law warns that consumers depend on observable behavior, including undocumented details, so changing an apparently purposeless interface element can break unseen dependencies. registry ↩