Perfection is not over-engineering
Perfection in software engineering is contested ground: some argue that with clear requirements there is a “perfect” solution, while others say real-world constraints, shifting goals, and human factors make that notion unrealistic or even harmful. Commenters contrast genuine technical quality and elegant simplicity with over-engineering — such as unnecessary microservice architectures or excessive testing — and stress that unclear or evolving requirements are a primary source of bloated systems. Many advocate a pragmatic middle path: aim for high quality where it matters, accept documented gaps and edge cases, and recognize that deadlines, budgets, and future change are themselves constraints that shape what “good enough” should mean.
What “over‑engineering” means
- Several definitions offered:
- Solving the wrong problem or optimizing for constraints you don’t actually have.
- Adding unnecessary complexity versus the payoff (e.g., many microservices for tiny user bases).
- Overbuilt vs over‑engineered: “too strong” vs “too complex for the requirements.”
- Some note the term is misused to mean “I don’t understand this” or to denigrate elegant abstractions.
Perfection vs “good enough”
- Many criticize “don’t let perfect be the enemy of good” as a cliché often used to justify shipping low‑quality, fragile systems.
- Others defend it as a way to prevent paralysis by endless polishing or handling ultra‑rare edge cases.
- Some argue “perfection” in engineering should mean “correctness against well‑defined constraints,” not neurotic perfectionism.
- Others say true perfection doesn’t exist; most problems have multiple trade‑off‑laden solutions, not a single optimum.
Requirements, constraints, and changing reality
- Strong theme: most over‑engineering comes from poor, missing, or constantly shifting requirements.
- Critics of the article’s thesis say:
- Constraints are flexible, trade off against each other, and change over time.
- You almost never have “every constraint on the table,” so claiming a unique “perfect” solution is unrealistic.
- Iterative approaches (build–observe–refine) are viewed as more honest given unknown unknowns.
Architecture choices and microservices
- Microservices repeatedly cited as classic over‑engineering when adopted for scale/HA/team‑independence that don’t exist.
- Some argue microservices primarily solve organizational scaling (Conway’s Law); reproducing that in tiny teams is “building an internal economy for a personal blog.”
Edge cases, reliability, and on‑call trade‑offs
- Debate over ignoring rare scenarios:
- Managers/product often push for 90th‑percentile solutions.
- Engineers responsible for 2am incidents resent being told to ignore rare but disruptive failures.
- Suggested compromise: explicitly document unsupported cases, log them, avoid blocking future evolution.
Testing, quality, and cost‑benefit
- Over‑engineering can appear as excessive unit‑test coverage or heavyweight QA that slows feature work while not improving real‑world reliability.
- Emphasis on cost‑benefit/FMEA thinking: invest heavily where severity and likelihood justify it, accept gaps elsewhere.
Perfectionism in practice
- Some see chronic non‑shipping side‑projects and endless rewrites as widespread perfectionism.
- Others say in professional environments the real problem is under‑engineered, spaghetti systems, not mythical perfectionists.