Write code that is easy to delete, not easy to extend (2016)

Design for Deletion vs Extensibility

• Many agree with the article’s premise: business apps change unpredictably, so code should be easy to throw away, not overdesigned for hypothetical futures.
• Over‑abstracting for “extensibility” often produces tightly coupled “platforms” that later become impossible to replace.
• Some argue that, over years in the same domain, you do learn to foresee recurring requirements, so a bit of forward-looking design can pay off.
• A minority view: if you really understand the “creases” of orthogonality, extensible design can be as simple as “deletable” design, but this is rare.

Frameworks, Architecture, and Over‑Engineering

• Business apps: keep it simple, use existing frameworks (Rails, ASP.NET, etc.), and avoid building your own “mini-frameworks.”
• Libraries/frameworks themselves arguably must target extensibility because they evolve slower and serve many consumers.
• Popular web frameworks and DI-heavy codebases are criticized for spreading logic across many classes, making deletion and refactoring hard.

Copy-Paste, DRY, and Abstractions

• Strong disagreement over copy‑paste vs abstraction:
  • One side: DRY reduces maintenance; copy‑paste multiplies bugs and divergence.
  • Other side: bad abstractions are worse than duplication; it’s easier to clean up 10 duplicated spots than untangle a wrong shared abstraction.
• Several rules of thumb:
  • First time write; second time copy; third or fourth time consider extracting.
  • Prefer extracting when pieces “change together,” not just when they look similar.

Simplicity, Intrinsic Complexity, and Scaling

• “Simple/straightforward is robust”: solve today’s problem, accept duplication, start with monoliths, scale when reality forces you to.
• Warnings that “simple” must still handle real edge cases; you can’t wish intrinsic business complexity away.
• Analogies (e.g., Wayland vs X11) highlight how misjudged simplification can produce more complexity elsewhere.

Testing and Observability

• Several note that deletion is only safe with automated tests and observability (metrics, deprecation signals, usage tracking).
• Tests themselves add complexity, but are seen as worth it, especially for refactoring legacy code and removing external APIs.

Tools and Future Automation

• Some hope future LLMs will load entire codebases and “clean up” or refactor safely.
• Others are skeptical about current capabilities and cost-effectiveness compared to human effort.