Practice : Refactoring

Purpose and Strategic Importance

Refactoring is the disciplined process of improving the internal structure of code without changing its external behaviour. It enhances readability, reduces complexity, and makes future changes easier and safer.

As systems grow, code inevitably degrades. Refactoring prevents entropy, manages technical debt, and supports sustainable delivery—keeping systems flexible, clean, and aligned to evolving business needs.

Description of the Practice

  • Refactoring involves small, safe, and incremental improvements to code structure, naming, duplication, cohesion, and complexity.
  • It is ideally performed in conjunction with adding features or fixing bugs (the “boy scout rule”).
  • Refactoring is supported by automated tests, linters, static analysis, and continuous integration.
  • Common techniques include extract method, rename variable, simplify conditionals, remove duplication, and clarify responsibilities.

How to Practise It (Playbook)

1. Getting Started

  • Embed refactoring into your Definition of Done—clean as you go.
  • Start with visible issues: long functions, nested conditionals, magic numbers, unclear naming.
  • Use linters and IDE tools to suggest simple refactorings automatically.
  • Prioritise areas with high churn, frequent bugs, or onboarding friction.

2. Scaling and Maturing

  • Establish a culture where refactoring is expected—not exceptional.
  • Track and address hotspots using metrics like code churn, complexity, or review comments.
  • Allocate regular capacity for refactoring in team planning or tech debt sprints.
  • Maintain a backlog of known refactoring opportunities and revisit them during planning.
  • Refactor tests and infrastructure code—not just application logic.

3. Team Behaviours to Encourage

  • Practice the “leave it better than you found it” mindset.
  • Propose refactorings in code reviews as part of normal feedback.
  • Celebrate refactoring wins and highlight before/after impacts.
  • Treat refactoring as a form of system care, not rework.

4. Watch Out For…

  • Large, risky refactors without tests or safety nets.
  • Refactoring for its own sake—focus on delivering maintainable value.
  • Avoiding refactoring because “there’s no time”—debt grows silently.
  • Lack of team alignment on code quality standards and practices.

5. Signals of Success

  • Code becomes easier to read, test, and modify over time.
  • Engineers are confident making changes without fear of regressions.
  • Tech debt metrics (e.g. code smells, complexity) improve.
  • Refactoring is planned and discussed alongside features.
  • Teams maintain a clean codebase even as delivery pace increases.