Keeping Code Changeable

Treat changeability as the asset: read the signals of decay, restructure safely, and pay down debt so the code keeps absorbing change cheaply.

Depth
Practical
Steps
8 existing graph entries
Start reading →
  1. 1
    Mental Model

    Design Is an Investment

    Deliberate effort spent on design up front is an investment that pays back by reducing future complexity and rework. Treating design as a cost to be minimized for short term speed accrues a debt that compounds. Strategic vs Tactical Programming — invest a small, continuous sha...

    Start from the stance: design effort is an investment that pays back by making future change cheap.

    Related within this path

    • References: Broken Windows
    • References: Code Smells
    • References: Don't Repeat Yourself (DRY)
    • References: Refactoring
    • References: Technical Debt
  2. 2
    Concept

    Technical Debt

    A metaphor for the cost of letting internal quality slide. Taking a shortcut in design is like borrowing money: it buys speed now, but you pay interest as every future change becomes slower and riskier until the debt is repaid by improving the design. Debt has two axes: it can...

    Name the liability: shortcuts borrow speed now against harder change later.

    Related within this path

    • References: Design Is an Investment
    • Related To: Broken Windows
    • Related To: Code Smells
    • Related To: Refactoring
  3. 3
    Concept

    Code Smells

    A code smell is a surface indication in code that usually corresponds to a deeper design problem. It is a heuristic, not a rule: a smell tells you where to look and that something may be worth improving, not what is wrong or how to fix it. Named smells (duplicated code, long f...

    Learn to read the surface signals that structure is starting to decay.

    Related within this path

    • References: Design Is an Investment
    • Related To: Don't Repeat Yourself (DRY)
    • Related To: Refactoring
    • Related To: Technical Debt
  4. 4
    Concept

    Refactoring

    Changing the internal structure of software to make it easier to understand and cheaper to modify, without changing its observable behavior. The discipline is the method: small, behavior preserving steps, each verified by tests, so that improving the design is decoupled from t...

    Restructure without changing behavior, so the code can keep taking on change.

    Related within this path

    • References: Design Is an Investment
    • Related To: Broken Windows
    • Related To: Code Smells
    • Related To: Technical Debt
  5. 5
    Concept

    Don't Repeat Yourself (DRY)

    Every piece of knowledge must have a single, authoritative, unambiguous representation in a system. DRY is about duplicated knowledge and intent, not merely duplicated lines of code; two pieces of code can look alike yet represent different knowledge, and identical knowledge c...

    Remove duplication so each decision lives in one place and changes once.

    Related within this path

    • References: Design Is an Investment
    • Related To: Code Smells
  6. 6
    Concept

    Naming

    A name is a tiny abstraction. A good name creates a precise, accurate image of the thing it refers to and quietly excludes what it is not. Names should be precise enough that a reader rarely has to look at the implementation, and consistent enough that the same word always mea...

    Make intent obvious through precise names, the cheapest abstraction there is.

  7. 7
    Concept

    Broken Windows

    Software rots the way a building does: one visible, unrepaired flaw, a "broken window", signals that no one cares, and invites more neglect until decay accelerates. The remedy is to fix small problems promptly rather than letting them accumulate into entropy. Quality erodes gr...

    Fix small decay early, before disorder becomes the accepted norm.

    Related within this path

    • References: Design Is an Investment
    • Related To: Refactoring
    • Related To: Technical Debt
  8. 8
    Mental Model

    Verification Over Authorship

    The durable difficulty in software was never typing the code; it was deciding what the code should do and establishing that it actually does it. Producing an implementation is the cheap, fast part; specifying intent precisely and verifying correctness is the scarce, hard, last...

    Close on the thesis: keeping code changeable is what lets verification, not authorship, stay the scarce work.