Martin Fowler defines refactoring as “Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improve its internal structure.”

I like to define it as “Refactoring is a systematic process of improving code without adding or taking away functionality. The purpose of refactoring is to clean up code and simplify the design.”

At its core, refactoring is making very small changes to simpler solutions. If you’re ripping out a whole chunk at once to replace it with a brand new clever solution, it’s not refactoring.

Refactoring should be done routinely as we work on files, but it should never be done without managing risk to the technology and business.

Why do refactoring?

Refactoring is done to improve the developer experience and simplify software.

Technical debt is accumulated through out the software development lifecycle. Over time, the code becomes less and less clean which results in making changes more and more difficult.

Clean code should be really important to any organization that is dependent on technology as it can slow down and even stall development. A lot of effort is wasted due to poorly designed and written code.

Refactoring makes a lot more sense than attempting to do a complete rewrite. Instead of attempting a really risky rewrite, it usually makes a lot more sense to add unit tests and refactor. Proper unit tests and capturing all requirements before hand is the only way to truly avoid a disaster.

What is Technical Debt?

I’ve previously blogged about technical debt, see my blog post “What is technical debt?” for the complete article. Technical debt can be summarized as being work that’s not quite right or work that could be done a lot better.

You should pay back technical debt by refactoring

Technical debt allows you to potentially get your product to market quicker, but there’s a cost of making that choice. The costs are very similar to servicing a loan or credit card.

Failing to pay back the technical debt will result in some of the follow problems:

• Potential customer / user problems because of bugs (availability or scalability issues).
• Technical debt means you will eventually deliver less value and/or deliver value slower which will impact the business.
• Poor developer experience, which means your team will not stay long.

A project will always have some level of technical debt, and that needs to be okay. No business can afford to fix every problem, but it needs to be managed. For the technical debt to be managed properly, somebody from the technology team has to speak to the business in terms that they can understand.

Typically when speaking to the business it’s best to stay really high level and explain what the impact would be on sales or support. Numbers need to be quantifiable (measurable, and specific). It’s best to show up with a solution.

Refactoring Summary

Refactoring shouldn’t be about adding new functionality but instead simplifying and making the code simpler. There’s a number of really good books out there about refactoring, managing technical debt, and clean code.

In Bob Martin’s book Clean Code a Handbook of Software Craftsmanship there’s a lot of effort spent on explaining how to produce clean code.

Managing Software Debt by Chris Sterling is a good resource for quantifying, and managing technical debt.