Justifying Refactoring — Vocabulary and Business Language

The Boy Scout Rule (Robert C. Martin): 'Always leave the campground cleaner than you found it.' Applied to code: each commit should leave the code slightly better — rename a variable, extract a method, remove a comment. Incremental improvement avoids the need for large, risky refactoring projects.

Non-technical stakeholders respond to business impact, not code quality. Effective justification: 'Feature X is taking 3x longer than it should because of [module]. Refactoring it will reduce future feature costs in this area by an estimated 60% and reduce the risk of [bug type].' Specific, measurable, business-outcome framing.

Opportunistic refactoring (Fowler) means improving code while working in an area for another reason — 'I'm adding this feature anyway, let me extract this method while I'm here.' It distributes refactoring effort across the development flow and avoids the need for large dedicated refactoring sprints.

Strangler Fig (Fowler, inspired by the strangler fig tree): build the new system alongside the old, routing new functionality to the new system while old functionality gradually migrates. The old system is 'strangled' until it handles nothing and can be deleted. Used for high-risk legacy migrations.

Technical debt is broader: rushed decisions, missing tests, poor architecture. Refactoring debt is the tracked, acknowledged subset: 'We know Module X needs to be extracted into a service — it's in the backlog.' Making debt visible in a debt registry (JIRA epic, ADR) separates it from vague technical debt conversations.