Designing Code for Change

Mon, 15 Jun 2026 00:00:00 +0000

Software changes. This is not a contingency — it’s the nature of software development. Requirements evolve. Systems scale. Technologies improve. Teams change. The useful question is not “will this change?” but “when it changes, how expensive will the change be?”

Code that’s designed for change is not over-engineered. It’s code where the natural boundaries of the design align with the natural boundaries of change. When a change is required, it affects a small, predictable, well-bounded area. When it’s not, the design hasn’t added unnecessary complexity “just in case.”

Technical Debt: Not All Debt Is Bad

Mon, 03 Mar 2025 00:00:00 +0000

Ward Cunningham introduced the technical debt metaphor to explain to non-technical stakeholders why code needed to be refactored. The analogy to financial debt was deliberate: sometimes you borrow money to move faster, and the interest compounds over time until the debt needs to be paid.

Over time, the metaphor has been stretched to cover every imperfect thing in a codebase. This is not useful. Not all debt is the same. Not all debt should be paid down.

Refactoring on dplabs — Software Engineering & Technology Consultancy

Designing Code for Change

Technical Debt: Not All Debt Is Bad