Write code that is easy to delete, not easy to extend (2016)
Software engineers debate the idea that code should be written to be easy to delete rather than easy to extend, arguing that over-engineered abstractions and premature frameworks often create rigid, hard-to-remove systems. Many advocate for simple, orthogonal designs, selective code reuse, and modular boundaries so that parts can be safely replaced as requirements inevitably change, especially in business applications. Others highlight trade-offs, noting the risks of excessive copy-paste, the importance of tests and observability when deleting code, and how intrinsic domain complexity can’t be wished away by simplicity alone.
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.