Working Effectively with Legacy Code¶

Feathers, M. C. (2004). Working Effectively with Legacy Code. Prentice Hall.

Type: Book
Intellectual base: Textbook
Year: 2004
ISBN: 9780131177055
Link: https://www.pearson.com/en-us/subject-catalog/p/working-effectively-with-legacy-code/P200000008984
Cited from: chemistry_materials, communication_media_studies, computer_science, military_strategic_studies, philosophy

Cited by¶

13 citations across 13 artifacts.

Each citation links to the sentence it supports in the citing article.

Primes¶

Chesterton's Fence
- Software — seemingly redundant code, configuration flags, and exception branches often encode bug-fix history; the discipline of reading the commit that introduced a line before deleting it is exactly this reasoning, and removing apparently dead code can resurrect forgotten bugs.
  This sourceEstablishes the discipline of understanding existing code (via characterization tests and reading its history) before changing it, so that apparently dead or redundant code is not deleted without recovering the behavior it encodes.
Dislocation Motion
- It recurs in software refactoring, where a large refactor of a coupled codebase is done not by stopping the world but by a refactoring front, often automated, that sweeps through one call-site or module at a time with cumulative effect.
  This sourceLarge refactors of coupled codebases proceed by an incremental front (seams, one call-site at a time) rather than a stop-the-world rewrite.
Legacy Integration
- Legacy integration names the middle path: identifying which legacy elements carry institutional value (memory, trust relationships, proven practices, cultural markers), designing transition mechanisms that honor them, and embedding them into new organizational forms, the architectural posture Feathers (2004) develops for working with legacy code.
Positional Advantage
- In software architecture it is the value of where a change sits: a clean architectural seam is a high-value position from which subsequent features are cheap and localized, while a tangled location forces sprawling, risky changes.
  This sourceDefines the 'seam' — a place where program behavior can be altered without editing in that place — as a high-value structural location from which subsequent changes are localized and cheap.
Refactoring
- The same paradox recurs in legacy codebases, calcified bureaucracies, and heritage buildings.
  This sourceEstablishes characterization tests as the load-bearing verification mechanism and the difficulty of refactoring verification-poor legacy systems (the renovation paradox).

Mechanisms¶

Characterization Test Harness
- Its strength is standing up a safety net fast where none existed
  This sourcePresents characterization tests as a safety net that captures existing behavior before legacy code is changed.
Golden Case Benchmark
- Its central trap is that it blesses current behavior including current bugs, so it can quietly lock in defects that someone downstream may already depend on.
  This sourceExplains that characterization tests preserve a system's actual current behavior, including questionable behavior on which deployed users may depend.
Golden Case Benchmark Set
- The technique is the classification cousin of golden master testing: pin the known-good outputs and alarm when they change.
  This sourceDescribes pinning observed outputs as test expectations and rerunning them to detect behavioral changes.
Golden Master or Trace Comparison
- Its central limitation is that it enshrines the incumbent, bugs and all — a golden master is a characterization of current behavior, not a statement of correct behavior, so it will faithfully demand that the substitute reproduce defects unless a human intervenes.
  This sourceExplains that characterization tests capture existing behavior, including surprising or buggy behavior, rather than defining correct behavior.
Golden-Output Regression Test
- It tests sameness, not correctness: it enshrines the current output as the reference even if that output is wrong, which is why it is precisely a characterization test — a snapshot of what the system does, not a check of what it should do.
  This sourceDefines characterization tests as documenting the behavior a system has today rather than asserting the behavior it ought to have.
Simplification Regression Suite
- Pinning current behavior as a reference before refactoring is the classic technique for changing code you do not fully understand.
  This sourcePresents characterization tests as a way to capture current behavior before safely changing code that is not yet fully understood.
State Diff Test
- Its strength is that it catches false purity empirically — the lazy write, the reused helper's side effect, the "read-only" action that isn't — by measuring real behavior rather than trusting the contract.
Topology Regression Suite
- Its central illusion is green-means-safe: the suite only proves the paths someone thought to encode, and the dangerous regression is usually the dependency nobody wrote a check for.
  This sourceTreats characterization tests as executable records of the actual behaviors that have been captured by the tests.

Verification¶

Does it exist? Confirmed. This work's ISBN resolves to a registered record, which fixes its identity. That is all it fixes.

Does it back the claim? Not recorded. Neither this nor any other of the 13 citations of this work carries a recorded support check.

Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.

Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.

See how references were verified.

Links previously used in the corpus¶

Before the registry existed this work was also linked 5 other ways.

Registry ID ref:bc7373e7c25a · see in the full table