“Starting from scratch costs a huge amount of money, it is very risky, and you are going to end up with huge amounts of bugs that you have to work through. If you take existing software, refine it, improve it, make it more secure and more user friendly, then it is actually a lot cheaper to do that.”

Developers shouldn’t refactor just to refactor, according to Schmelzer. “It is really a matter of when is refactoring a tool for accomplishing the business goal or satisfying the business need that you are being asked to address,” he said. “It is really a matter of ensuring what the value you are trying to get out of doing that work. If you don’t know the value you are trying to achieve, then I would question doing it.”

More often, businesses turn to refactoring as a way to modernize their existing applications. According to Schmelzer, businesses across all industries are being asked to extend the reach of their software to new scenarios and new use cases to provide new value. “To do that you need to restructure the code to expose things in new ways, and that is where techniques like refactoring start to come in and become very beneficial because it is a more structured way of thinking about how you reorganize and change the code without impacting the behavior of the application,” he said.

An example of this is the travel industry. In the past, customers had to directly call travel agents to get help with booking. With all the new technologies and devices today, customers can book directly through a reservation system. Businesses in the travel industry had to take their existing systems and modernize them to meet customers’ demand for new interactions. “You want the same logic to be there. You want to ensure all the logic around calculating fare, connecting flights, and flight availability is there and consistent,” said Schmelzer.

“Most likely the system wasn’t originally designed in a way that you could easily plug in new entry points into that logic, so developers have to go and start a refactoring operation to expose that core central logic in a way that is now accessed from multiple different experiences.”

These legacy apps also accumulate a tremendous amount of technical debt over time, leading to code breaks and unnecessarily hurdles in your workflow. Similarly to financial debt, technical debt incurs interest, but instead of in the form of money, it comes in the form of added work for developers. Technical debt often occurs when developers are trying to cut corners or aren’t trained properly, which causes code to become sloppy and hard to work with.

Refactoring can help eliminate technical debt by making a dirty design “clean,” which in turn helps speed up the process of future development. “Refactoring allows me to explicitly explore code, reach into code, hear what it is trying to say about the problem and business domain, reflect from what is there, and then find ways to make that similar, more expressive and as a result dramatically reduce errors, and reduce the complexity of implementing work,” said Industrial Logic’s Belshee.

In general, refactoring should happen when the opportunity calls for it, according to Hadi Hariri, developer advocacy team lead for JetBrains. “If I’m working on some code, and I see something can be simplified and is called for, then refactor. The notion of delaying refactoring for some magical moment in time doesn’t work that well,” he said.

How often should you refactor?
There are two ways to refactor your code: at a micro level and at a larger level, according to Microsoft’s Schmelzer.

About Christina Cardoza

Christina Cardoza, formerly known as Christina Mulligan, is the Online & Social Media Editor of SD Times. She covers agile, DevOps, AI, and drones. Follow her on twitter at @chriscatdoza!