keep-it-simple

Avoid premature abstraction until you have at least 3 concrete, real use cases. The Rule of Three prevents over-engineering by deferring factory patterns, abstract base classes, and config-driven features until genuine duplication emerges. Implement the simplest working solution first.

YAGNI (You Aren't Gonna Need It) means building only what's required now, not speculative infrastructure. Before adding factories, abstract layers, or configuration systems, verify you have multiple concrete requirements. Keep design decisions simple and defer complexity until evidence justifies it.

Use explicit criteria: check if you have 3+ distinct use cases before abstracting. If you have fewer, implement a straightforward, concrete solution. This approach balances code maintainability against unnecessary complexity, guiding practical refactoring decisions.

Enforce YAGNI checks before creating abstract base classes, configuration-driven features, or infrastructure abstractions. Apply the Rule of Three and simplicity criteria to distinguish between justified abstractions and premature complexity that adds maintenance burden without current value.

Premature abstraction increases complexity, maintenance cost, and cognitive load without solving real problems. It often creates rigid patterns that don't fit actual use cases. Deferring abstraction until you have concrete duplication keeps codebases simpler and more adaptable.