Refactoring and technical debt

Importance of refactoring

Refactoring and technical debt are important concepts, especially so in agile software development. What are they?

Refactoring is modifying the internal structure of code without changing its behaviour. All functional tests should pass with the same results after the code has been refactored. If it behaves the same, why do we need to do it?

Refactoring is important to maintain the long-term quality of the code and platform of which the code is a part. If the developers don’t do some refactoring on a regular basis, “technical debt” will creep into the system. It will continue growing to the point where new development becomes difficult if not impossible. In my experience, the overall technical debt of a system increases exponentially (not linearly) as the technical debt of individual parts increases. That is because the technical debt of a given part increases as the overall complexity and entropy of the system increases.

Technical debt, micro and macro

I believe there are actually two types of technical debt: micro and macro. Most technical debt is micro: that belonging to a single component. Macro tech debt is related to the overall architecture of a system. That is, how the components interact with each other. You should be repaying micro tech debt continuously you are building stories. Refactoring is a development practice that should be part of the standard process that developers follow as they deliver stories. If you are following Test-Driven Development practices, this is explicitly clear: the process goes Red, Green, Refactor. Red: write a test that fails. Green: write some code that makes the test pass. Refactor: improve your code.

Refactoring and technical debt

Macro technical debt is more complex and generally requires embarking an explicit project, with its own features, stories, product owner, etc. Getting buy-in from stakeholders can be difficult for these projects, and will require careful thinking and communication around the benefits. Some examples of macro technical debt could be:

  • moving from a vendor product to an internally developed one
  • changing from a monolithic application model to a microservices model
  • porting from one technology stack to another (e.g. LAMP to MEAN).

When not to refactor

When refactoring, make sure you are doing it for a specific reason! Do not refactor if you can’t think of a benefit. Some examples include:

  • improving performance
  • improving scalability
  • reducing brittleness / adding error handling
  • increasing reusability
  • improving testability / test coverage.

Leave a Comment:

1 comment
Add Your Reply