Thinking Triz

TRIZ

Resolve technical design contradictions without midpoint compromise. Name the conflict, separate the opposing states, and transform the system so both benefits hold.

When to Use

• Architecture, API, or system parameters pull in opposite directions (stable vs evolving, fresh vs cached, strict vs frictionless).
• You are about to accept a trade-off because "you can't have both."
• Every candidate solution shares the same structural weakness—the conflict is in the requirements, not the options list.

When NOT to Use

• One option is simply better under stated constraints → pick it; do not manufacture a contradiction.
• A cheap measurement shows which side actually matters → measure instead of inventing a separation.
• A standard pattern already resolves it (cache-aside, CQRS, feature flags, versioning) → apply the pattern directly.
• Non-technical people/org conflicts → out of scope; separation targets system parameters.
• Ordinary prioritization or resource allocation without opposing states of the same parameter.

Procedure

• Name the contradiction in template form. Write: "We need [PARAMETER] to be [STATE_1] for [BENEFIT_1] BUT [STATE_2] for [BENEFIT_2]." If this form fails, stop—use another method.
• State the ideal final result (IFR). Describe both benefits held with minimal new machinery and no permanent midpoint sacrifice.
• Try separation before invention. Test, in order: time (different moments), space (different components/layers), condition (context, load, risk), scale (interface vs implementation, aggregate vs element). Keep the first separation that delivers both benefits without hidden compromise.
• If separation fails, apply an inventive transform. Prefer resource-light moves: segmentation, preliminary action, inversion (push/pull), intermediary, copying/replication, dynamization (flags/config), another dimension (metadata/versioning/events). Scan only principles that map to the named parameter conflict.
• Reuse existing resources first. Before adding services or stores, check data, traffic, headers, schedulers, and side effects already present that can carry the separation.
• Lock a concrete resolution and stop. Specify the design change, where each state lives, and how both benefits are preserved. Stop when a no-compromise design is stated, or when honest analysis shows only a constrained trade-off remains—then document the residual trade-off explicitly rather than forcing TRIZ theater.

Output

Emit a TRIZ resolution:

• contradiction: parameter / state_1+benefit_1 / state_2+benefit_2
• ideal_final_result: both benefits without permanent compromise
• separation_tried: time | space | condition | scale → result each
• inventive_move: principle or pattern used if separation alone was insufficient (or none)
• resources_reused: existing capabilities leveraged
• resolution: concrete design decision and where each state holds
• residual_tradeoff: none, or the honest remaining compromise

Verification

• Template gate: if the contradiction cannot be written in the required form, do not apply TRIZ.
• No-compromise check: a pure midpoint on the trade-off curve without a separation or inventive move is a failed application.
• Separation-first: principles without attempted time/space/condition/scale separation are incomplete.
• Over-application guard: if measurement or a standard pattern settles the design, skip TRIZ.
• Stop: one named contradiction → separation/inventive pass → concrete resolution; do not cycle principles as decoration.