Against Best Practices
Software engineers are reexamining the idea of “best practices,” arguing that rules like DRY, “no globals,” or Postel’s Law are often applied dogmatically without regard for context, project scale, or risk profile. Many see value in shared conventions as guardrails, communication aids, and on‑ramps for less experienced developers, but warn that cargo‑culting them can lead to over‑engineering, misplaced authority, and poorer outcomes. A recurring theme is that practices should be treated as context‑dependent starting points grounded in clear rationale, not universal laws that replace judgment or understanding of trade‑offs.
Role and Limits of “Best Practices”
- Many see “best practices” as useful shortcuts: distilled experience that avoids re‑deriving everything from first principles, improves consistency, and speeds novices.
- Others stress they are only heuristics, not laws; they should be starting points, not unquestionable authority.
- Several commenters argue the article’s real target is dogmatic, context‑blind application, not the practices themselves.
Context, Risk, and Domain Differences
- Repeated theme: best practices are inherently context‑dependent. What’s right for avionics, trading platforms, or cryptography differs from a marketing site or indie game.
- Risk appetite matters: in high‑risk domains, strict adherence to conservative practices is favored; in low‑risk/high‑reward domains, experimentation is encouraged.
- Practices may also change as systems evolve (e.g., MVP that becomes critical infrastructure).
Other Engineering Disciplines and Standardization
- Some note traditional engineering uses standards, certification, and regulation, driven by safety and liability; software often lacks such external pressure.
- Others counter that even in mechanical/civil engineering, “best practices” are numerous, context‑sensitive, and far from universally agreed.
- A body of knowledge (e.g., SWEBOK) is cited as more about cataloging techniques than prescribing universal rules.
DRY, Globals, Postel’s Law, and Specific Rules
- DRY is discussed as frequently misunderstood: avoiding duplication only makes sense when semantics and future changes align; otherwise it can violate single responsibility and over‑abstract.
- “Never use globals” is seen as overreach; globals can be acceptable for truly global state, but overuse creates maintenance nightmares.
- Postel’s Law is viewed by some as still helpful, others as outdated and harmful in modern security‑sensitive contexts.
Team Dynamics, Power, and Cargo Culting
- “Best practice” is often used as an argument from authority or a cudgel in code review, especially by zealots or less‑experienced developers.
- This can lead to cargo culting, over‑engineering, and resentment, particularly when reasons aren’t explained or documented.
- Several suggest explicitly documenting why a guideline is being broken in a PR, and emphasizing discussion of trade‑offs rather than rule‑recitation.
Terminology and Alternatives to “Best”
- Multiple commenters dislike the word “best”; propose “standard practice,” “current common practice,” “golden path,” or simply “practices.”
- Consensus of sorts: treat them as widely used defaults, to be followed by default but abandoned when you can clearly articulate why they don’t fit.