Recognizing overengineering

Overengineering adds abstraction, indirection, configurability, or patterns whose cost exceeds current problem value. Signals: frameworks solving problems you do not have, interfaces with one implementation, feature flags for unreleased ideas, and diagrams thicker than the code.

Ask: what user pain does this layer remove today? If none, defer or delete.

On interviews: critique a sample architecture with unnecessary event bus and propose a simpler path.

Common pitfalls: resume-driven design, copying big-tech patterns at startup scale, and fear of future rework blocking shipping.

The trade-off is theoretical future-proofing versus team velocity and comprehension.

Checklist:

• Tie every layer to current pain or risk.
• Count implementations per abstraction.
• Prefer delete over unused generality.