Optimization Backlog with Trigger Conditions¶
Tracking registry — instantiates Refinement Timing Guardrail
Keeps deferred optimizations in a visible list, each tagged with the measurable condition that should fire it — so good ideas are neither forgotten nor done too early.
Telling a team "not yet" only works if "not yet" has somewhere to live. Optimization Backlog with Trigger Conditions is that place: a running, visible list of refinements the team has chosen to defer, each entry carrying not just a description but a measurable trigger — the condition under which it graduates from "someday" to "now." Its defining move is the trigger. A plain backlog is a graveyard of good intentions; this one attaches to every deferred item a specific, checkable firing condition ("optimize this query when p95 latency exceeds 200ms," "add this abstraction after the third independent caller appears") so that the decision to act is made by evidence arriving, not by whoever remembers the item or feels the itch to build it. It preserves the idea without doing the idea.
Example¶
A game studio is building a multiplayer strategy title. During the prototype phase, ideas for optimization arrive constantly: a spatial index to speed up unit collision checks, an object pool to cut garbage-collection stutter, a level-of-detail system for distant models, a network-compression pass. Any of them could eat a sprint. Instead of building them — or losing them — the team logs each into an optimization backlog, and here's the discipline: nothing goes in without a trigger.
So the spatial index is filed as "build when a representative battle exceeds 300 simultaneous units AND collision checks show up as >5% of frame time in a profile." The object pool is "build when GC pauses exceed 2ms in a captured play session." The network pass is "build when average match bandwidth exceeds the target ceiling under an 8-player test." Months later, playtests with real battle sizes fire exactly one of these — the spatial-index trigger — because unit counts blew past 300 and profiling confirmed collision checks were now the frame's dominant cost. The team builds that one, with evidence in hand, and leaves the others sleeping in the backlog, their triggers still unmet. The optimizations that turned out not to matter were never built; the one that did was built exactly when the data said so.
How it works¶
- Log the candidate, not just a wish. Each entry names a specific refinement precisely enough to be estimated and built later without re-deriving it.
- Attach a measurable trigger. Every item carries a checkable firing condition — a threshold, a count, a profiled signal — chosen so its arrival is evidence that the refinement now matters.
- Prefer evidence-shaped triggers. The best triggers reference whole-system measurements (a bottleneck that shows up under real load) rather than calendar dates or gut feel.
- Review on cadence, act on fire. The list is scanned periodically to check which triggers have tripped; only fired items are pulled into active work, and un-fired items are re-examined for whether their premise still holds.
Tuning parameters¶
- Trigger tightness — how demanding each firing condition is. Tight triggers wait for strong evidence and minimize wasted work but risk acting slightly late; loose ones act sooner but reopen the door to premature optimization.
- Review cadence — how often triggers are checked. Frequent reviews catch fired items fast but cost meeting time; rare reviews let the backlog drift out of sync with reality.
- Entry bar — how much justification an item needs before it earns a slot; a high bar keeps the list short and meaningful, a low bar captures everything but buries the signal.
- Staleness policy — how aggressively un-fired items are pruned when their premise expires, versus kept indefinitely as a wish-list.
When it helps, and when it misleads¶
Its strength is that it resolves the tension every disciplined team feels — the fear that deferring an optimization means losing it. By making deferral a tracked state with an automatic reopening condition, it lets a team honor Knuth's warning against premature optimization[n1] without pretending the ideas never existed. Good instincts are banked; only the evidence decides when they're spent.
Its failure mode is the backlog that becomes a comfortable place to bury things and never look again: triggers written vaguely ("optimize when it feels slow") never objectively fire, the review lapses, and the list rots into an alibi for inaction while real bottlenecks go unaddressed. It can also invert into over-triggering, where too-loose conditions fire a cascade of optimizations that reintroduce the premature-work problem the backlog was meant to prevent. The guarding discipline is to insist every trigger be objectively checkable and to actually run the review — an unmeasured trigger is a wish, and an unread backlog is a landfill.
How it implements the components¶
refinement_backlog_with_triggers— this is the mechanism itself: a persistent list of deferred refinements, each bound to its firing condition.local_refinement_candidate— every entry names a specific proposed optimization concretely enough to schedule and build when its trigger fires.bottleneck_evidence_signal— the strongest triggers are evidence conditions (a profiled threshold, a measured load) that fire only when the item is shown to matter to the whole.
It does not implement reversibility_and_lock_in_assessment or exception_path_for_critical_refinement — the rationale for one deferral and its override condition belong in a Decision Record with Deferred Refinement; the backlog tracks a queue of items and their triggers, not the prose argument behind any single one.
Related¶
- Instantiates: Refinement Timing Guardrail — the backlog is how deferred refinements stay visible and reopen on evidence.
- Consumes: Representative Workload Profiling supplies the measured signals many triggers fire on.
- Sibling mechanisms: Decision Record with Deferred Refinement · Representative Workload Profiling · Refinement Readiness Checklist · Local–Global Metric Trace · Architecture Skeleton or Walking Skeleton · Pre-Optimization Review Ritual · Reversibility Tag or Feature Flag · Timeboxed Optimization Spike
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Optimization Backlog with Trigger Conditions operates as a persistent ledger, log, register, or case record that preserves history and traceability because it keeps deferred optimizations in a visible list, each tagged with the measurable condition that should fire it — so good ideas are neither forgotten nor done too early.
Independent corroboration: The frozen evidence defines Optimization Backlog with Trigger Conditions as 'Keeps deferred optimizations in a visible list, each tagged with the measurable condition that should fire it — so good ideas are neither forgotten nor done too early', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: The mechanism operationalizes software-engineering discipline against premature optimization by tying deferred work to measured performance triggers.
Related originating lineages:
- Organizational & Management Science — Optimization Backlog with Trigger Conditions is most directly rooted in organizational and management science's practice of coordinating people, authority, strategy, knowledge, and work. The lineage fits its defining practice: Keeps deferred optimizations in a visible list, each tagged with the measurable condition that should fire it — so good ideas are neither forgotten nor done too early.
Review resolution: Authoritative-source research resolves the primary-origin disagreement in favor of computer science. Incident Response — Google SRE Workbook documents the formative practice or theory represented here. The retained alternate domains identify material co-development or translation, while current applicability is recorded separately as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis describes the historical relationship among lineages.
Attribution caveat: This named registry is an encyclopedia synthesis around established software and product-management practices.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
Notes¶
[n1] Donald Knuth's much-quoted line — "premature optimization is the root of all evil" — was a caution about optimizing before profiling has shown where the time actually goes; the backlog operationalizes it by refusing to act until a measured trigger fires. ↩