Change And Maintenance

Back to Glossary.

Changeability

Changeability is the ease with which a system can be modified without creating disproportionate cost, risk or confusion.

It depends on many factors: boundaries, naming, testability, coupling, clarity of intent, tooling and the local complexity of the code being changed. A system with good changeability does not make every change cheap, but it keeps changes legible, scoped and predictable.

In practice, changeability is often a more useful measure of engineering quality than elegance in isolation.

Refactoring

Refactoring is the disciplined improvement of code structure without changing the intended external behavior of the system.

Its purpose is usually to improve readability, changeability, boundaries or local design quality. Refactoring is most valuable when it reduces future cost, clarifies intent or removes friction from real upcoming work.

Technical debt

Technical debt is best used as a tradeoff metaphor, not as a blanket label for anything imperfect.

Technical debt appears when a team knowingly accepts a weaker implementation, shortcut or structural compromise in exchange for something concrete: time, learning, delivery momentum or reduced coordination cost.

What makes it debt is not the flaw alone, but the combination of intentionality, expected payoff and future cost. If none of that is explicit, the situation is closer to neglect than to debt.

Related reading: Technical debt should buy something real.

Legacy

Legacy is not a synonym for age, an outdated stack or technical debt.

Legacy is software that is no longer meaningfully maintained through shared understanding. It is usually shaped by accumulated history, constraints, compatibility obligations and decisions that continue to influence the present, but the practical hallmark is not age alone. The hallmark is the loss of reliable support knowledge around the code.

That loss often shows up as missing tests, weak or outdated documentation, and sometimes the absence of people who still understand how the system actually works. In that state, even routine change becomes (non-)guesswork.

A system can be old without being legacy in the meaningful sense, and a fresh codebase can become legacy surprisingly early. That happens when code is written, shipped and effectively abandoned at the knowledge level from the very beginning, so the understanding of how it works disappears almost immediately.

Legacy becomes technical debt only when the decision to keep living with a problematic legacy structure is conscious, understood and still postponed despite real pressure to change it.

Related reading: Legacy is not automatically technical debt.

Controversial technical decisions

Controversial technical decisions are a separate category from legacy and technical debt, even though they can be related to both.

This term is useful for solutions that are questionable, debatable, weakly justified or visibly risky, but are not automatically legacy and do not automatically qualify as debt. A decision can be controversial simply because its tradeoffs are disputed, its context is unclear or its costs are becoming visible before the team has decided how to classify it.

Naming such decisions explicitly is often useful. It creates room to discuss quality, risk and alternatives without collapsing everything into either technical debt or legacy.

At the same time, precise naming matters just as much. Not every bad or disputed decision is legacy. Not every uncomfortable design is debt. Clear language helps separate historical burden, explicit tradeoffs and merely questionable judgment.