Perfection Is Not Over-Engineering: Solving the Right Problem
Perfection Is Not Over-Engineering
I argue that over-engineering isn't about caring too much or making things too good; it's simply solving the wrong problem. When we treat systems as products and gather clear requirements, a perfect solution naturally emerges as the only one that fits. The real enemy is ambiguous requirements, not the pursuit of excellence.
"Over-engineering is solving the wrong problem. That's the whole definition. Not caring too much. Not making it too good."
HN discussion
- One commenter strongly rebuts the article's thesis, arguing that over-engineering is defined by spending excessive resources on a solution rather than solving the wrong problem, citing a custom CUDA image converter versus a simple shell script as an example where both solve the correct problem but one is still over-engineered.
- Senior engineers often prioritize the 80/20 rule, accepting imperfection and edge cases to deliver 80% of the desired result with minimal complexity, recognizing that constraints change too rapidly for perfect optimization to remain valid.
- While the article champions 'good enough,' some practitioners argue for 'good, not good enough,' drawing a line at architecturally weak or janky solutions that may ship quickly but create long-term technical debt.
- A former initiator of a rewrite shares a cautionary tale where a team switched from C to Go to accommodate existing developers, only to have the rewrite scrapped once a competent C developer was found, highlighting the risk of solving personnel constraints with architectural changes.
- The pursuit of perfection in software is often counterproductive because it assumes a static ideal, whereas reality requires accepting 'the bad' and living with limitations to avoid the Sisyphean trap of never finishing a project.