Living with old code

It often starts with a piece that looks like it does nothing.

Chesterton's Fence

§ 3 · SystemsCode or rules whose origin you don't know look like clutter, which makes them tempting to delete.Keep in mind: Learn why it is there before you remove it, but set a deadline on the search

Learning why it is there often means asking the people who built it, and they may be gone.

Programming as Theory Building

§ 104 · MaintainabilityA program's design lives in the heads of the people who built it, and the code and documents carry only part of it, so once those people are gone, changes tend to erode the design even with full documentation in hand.Keep in mind: Code stays maintainable only while someone can say why it is the way it is

Even they could not list everything it is relied on for. That list is held by its users.

Nobody gets to wait until the code is understood again, because code still in use keeps being changed.

Lehman's Laws of Software Evolution

§ 93 · MaintainabilityA program in real use must keep changing or grow less useful, and each change makes it more complex unless work is spent to simplify it.Keep in mind: Budget for simplifying, not just for changing

Some of that complexity was taken on knowingly, by shipping before the problem was fully understood, and that part can be recorded as a loan.

Technical Debt

§ 92 · MaintainabilityCode shipped before the team fully understands the problem charges extra on later changes to that code until someone rewrites it.Keep in mind: Record shortcuts as loans, and repay them where you change code most

Part of it can be paid back without waiting for a project of its own.

Boy Scout Rule

§ 29 · MaintainabilityCode decays because cleanup tends to be deferred to a refactor that rarely happens.Keep in mind: Leave what you touch a little better, in the same diff

When small repairs feel too slow, the other urge from the start takes over, and a rewrite tempts you to fix more than was broken.

Second-System Effect

§ 65 · SystemsAfter a first success, designers tend to pack the ideas they deferred into the second system.Keep in mind: In a rewrite, carry over the constraints, not the wish list

A rewrite also gives up something the old system already has: it works.

Gall's Law

§ 6 · SystemsComplex systems that work usually grew from simple systems that worked; designed ones rarely do.Keep in mind: Distrust a design that has to work all at once to work at all

If a replacement has to grow from something that works, the old system can be that something.

Strangler Fig

§ 90 · MaintainabilityReplacing a live system piece by piece around its edges is usually safer than replacing it all at once.Keep in mind: Make every step of a migration shippable, and plan the deletion up front

Each piece moved can break someone who relied on the old behaviour, and the people moving it see only what a test checks.

Beyoncé Rule

§ 87 · MaintainabilityIn a shared codebase, the behavior no test checks is the behavior that changes without warning.Keep in mind: If you depend on it, put a test on it