Compare engineering options

Trade-Off & Lifecycle Cost Analysis

Use this skill when comparing architectural alternatives, build-vs-buy decisions, or "quick workaround vs. structural fix" choices so the team optimizes for total lifecycle cost rather than initial typing speed alone.

Dimensions of Full Lifecycle Cost

Evaluate every option across five concrete dimensions:

1. Implementation & verification effort: Time and risk to build, test, review, and deploy the change in the current codebase (calibrated with the implementing developer, noting uncertainty explicitly).
2. Ongoing operational & manual burden: How often will engineers, support, or users have to intervene manually? How many new alerts, queues, migrations, or secrets must be maintained?
3. Cognitive load & change amplification (Ousterhout): When requirements change next month, how many files, services, and mental models must a developer understand to make a safe edit?
4. Blast radius & reversibility: Is this a two-way door (easy to change or remove later, like an internal function signature) or a one-way door (hard to reverse, like a public API contract, persisted schema, or customer-facing pricing model)?
5. Cost of delay & batch size (Reinertsen): Does bundling extra work delay the core value and increase merge/deployment risk?

Workflow

1. Compare at least two realistic options side by side:
   • Option A (Minimal Complete): Uses existing stack primitives, solves the current validated requirement, and documents clear limits.
   • Option B (Expanded / Generalized): Adds new infrastructure, abstraction, or broader scope.
   • State the concrete pros, cons, failure modes, and operational costs of each — never claim time or cost savings using invented percentages.
2. Apply the Two-Way Door rule:
   • For reversible internal decisions, always choose the simpler Option A now and defer Option B until real usage triggers it.
   • For irreversible boundaries (public APIs, persisted data schemas, security/permission models, financial ledgers), invest upfront to get the data model and invariants right even if the initial UI or feature surface stays minimal.
3. Reject the Sunk-Cost Fallacy:
   • Never justify continuing a complex, fragile, or off-target implementation merely because significant time or code has already been invested in it. Evaluate only the remaining cost to finish, verify, and maintain vs. switching to a simpler approach.
4. Coordinate cross-role constraints:
   • Align product outcome with the product analyst, architectural trade-offs with the architect, implementation effort with the developers, and non-negotiable quality/security floors with the debugger and security reviewer.