proomt

Search

Search posts, papers, and topics

Hall of Fame

Hall of FameJoel Spolsky20006 min readintro

Things You Should Never Do, Part I

Summary

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.

  • A full rewrite discards years of bug fixes and real‑world testing embedded in the existing code.
  • Incremental refactoring can address architectural, performance, or style problems without losing working functionality.
  • New code is not inherently better; proven old code already survived many edge cases.
  • Large rewrites delay product releases and give competitors a market advantage.

Engineering leaders and developers should care because a rewrite can waste time, money, and market position while offering no guarantee of improvement.

5/10

Related reading

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

    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.

    Hall of Fameprogrammingisterrible.com15 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. No Silver Bullet: Essence and Accidents of Software Engineering

    Brooks argues that software development’s fundamental difficulty lies in essential complexity—conceptual design, conformity, changeability, and invisibility—rather than accidental implementation issues. Consequently, no single technology or management trick will yield an order‑of‑magnitude productivity boost; progress must come from disciplined, incremental improvements.

    Hall of Fameunc.edu34 minpaper
  4. Out of the Tar Pit

    The paper argues that most complexity in large software systems is accidental, caused mainly by mutable state and tangled control flow. It proposes minimizing accidental complexity by using pure functional programming together with a relational data model, emphasizing simplicity over extensive testing.

    Hall of Famecurtclifton.net98 minpaper