Perfectionism – one of the biggest productivity killers in the eng industry
Perfectionism in software engineering is alternately blamed as a productivity killer and defended as a necessary counterweight to today’s “ship fast, fix later” culture. Commenters argue that the real issue is balancing short‑term delivery with long‑term quality: rushing leads to fragile, debt‑ridden systems, but polishing low‑value details or refactoring for aesthetics can also waste time. Many conclude that context, clear requirements, and thoughtful prioritization—rather than blanket praise or condemnation of perfectionism—should guide how much rigor to apply.
Perfectionism vs “Good Enough”
- Many argue true perfectionism is rare; the dominant problem is shipping half‑baked software and never coming back to fix it.
- Others say perfectionism does exist, especially as polishing, refactoring, or chasing tiny performance gains long after value flattens.
- Some note the cliché “don’t let perfect be the enemy of good” is often abused to justify poor quality rather than legitimately “good enough” work.
Context, Risk, and Tradeoffs
- Several emphasize productivity as an optimization problem: acceptable quality depends on domain (prototype vs critical infra, kernel modules, ICS, aviation, etc.).
- Key question: is a 95% solution shippable now with a realistic path to 99% later, or will constraints freeze the system at 95% forever?
- High‑impact, hard‑to‑change decisions (architecture, safety‑critical paths) are seen as worth more “perfectionism”; minor naming/structure less so.
Quality, Tech Debt, and Industry Sloppiness
- Many report most industry code is “barely working,” with high warning counts, poor testing, and rushed releases.
- Tech debt and “we’ll fix it later” that never happens are cited as major, compounding productivity killers.
- Some tie the culture of “minimum viable” and speed‑at‑all‑costs to systemic failures (e.g., CrowdStrike outage, Boeing problems).
Management, Requirements, and Blame
- Commenters complain managers simultaneously punish “perfectionism” and then punish resulting defects.
- Poor or changing requirements are repeatedly named as a larger productivity killer than perfectionism.
- There is disagreement on whether engineers should interact directly with stakeholders; intermediaries can both help and hinder.
Clean Code, Overengineering, and Abstractions
- Distinction drawn between:
- Valuable diligence: tests, error handling, monitoring, clarity, modularity.
- Harmful “perfectionism”: needless refactors, over‑abstracted architectures, rewriting working code for style.
- Some stress that clean, modular code enables testing and long‑term velocity; others warn against dogmatic patterns and excessive layering.
Perfectionism as Psychology vs Process
- One line of discussion treats perfectionism as a clinical anxiety issue: fear of shipping anything imperfect.
- Several argue the article conflates this with inexperience and mis‑prioritization, which are separate problems.
Suggested Practices
- Commonly endorsed: write down priorities, ship small increments, seek early feedback, use “rule of three” for abstractions, and reserve real perfectionism for the parts where failure truly matters.