design-it-twice

To compare software design alternatives, generate at least two fundamentally different approaches for your class, module, or API, then evaluate them by caller ease-of-use, interface simplicity, generality, implementation complexity, and performance before implementation.

Comparing divergent API design options prevents premature commitment by forcing a structured evaluation of clean-room alternatives, ensuring you select or synthesize the option that best reduces caller complexity rather than accepting the first plausible design.

Trade-off analysis for software architecture is the structured comparison of fundamentally different design approaches by concrete metrics like performance and interface simplicity, needed before implementing significant system decisions, RFCs, or new data-access layers.

To generate independent design alternatives when an existing design is present, use an isolated alternative-design agent for clean-room exploration, or apply a pre-mortem fallback analysis if isolated agent support is unavailable.

Yes, you can use this structured comparison approach for both high-level system architecture and low-level API design, as it applies to classes, modules, design documents, and other significant interface or system decisions.

Without isolated agent support, clean-room alternative generation cannot independently explore divergent designs, requiring a pre-mortem fallback to anticipate potential failures and evaluate trade-offs within the existing design context instead.