proomt

Search

Search posts, papers, and topics

Hall of Fame

Hall of Fametef201615 min readintermediate

Write code that is easy to delete, not easy to extend

Summary

The article argues that code should be written to be easy to delete rather than to be reusable, advocating duplication, layering, and disposable implementations. It suggests copy‑pasting early, isolating hard‑to‑change parts, using thin wrappers, and accepting big, throw‑away code to simplify future removal.

  • Copy‑paste early; only refactor to a shared function after duplication proves useful.
  • Separate utility code from business logic to keep concerns isolated.
  • Layer APIs with thin, opinionated wrappers over lower‑level libraries.
  • Write disposable, large‑scale code first and delete whole sections later rather than many tiny changes.

Software engineers maintaining long‑lived codebases should care because the advice targets reducing future maintenance cost by designing for easy removal.

5/10

Related reading

  1. Things You Should Never Do, Part I

    Joel Spolsky argues that rewriting a mature codebase from scratch is usually a strategic mistake, because it throws away bug fixes and delays shipping. Incremental refactoring of architecture, performance, or style issues is far safer.

    Hall of Famejoelonsoftware.com6 min
  2. Using coding agents on a migration: Three practices that mattered

    Coding agents proved most effective for cleaning up temporary code and legacy configurations during a migration, rather than for initial code construction. This effectiveness stemmed from three specific practices: documenting cleanup needs upfront, co-locating rules with code and their enforcement, and actively managing instruction staleness.

    Temporaltemporal.io7 min
  3. Database Branching: A Developer's Guide to Git-Style Workflows

    Database branching uses copy‑on‑write to give developers, CI jobs, and AI agents isolated database snapshots without full copies. Branches share unchanged data, store only deltas, and are disposable, enabling production‑like testing, per‑PR isolation, safe experimentation, and rapid cleanup. Safe operation requires protecting parent branches, using mock data, TTLs, and treating migrations as the…

    Databricksdatabricks.com9 min
  4. Immutability in PHP Beyond readonly

    The article walks through practical ways to achieve immutability in PHP beyond the built‑in readonly keyword, covering interior mutability, immutable value objects, collections, dates, and cloning. It also shows how to enforce and test these patterns in real codebases.

    Freek Van der Hertenfreek.dev1 min
  5. Simple Made Easy

    Rich Hickey argues that simplicity, not easiness, is the foundation of reliable software. He outlines how to choose simple constructs and design abstractions to keep systems understandable and changeable.

    Hall of Fameinfoq.com9 mintalk