“Refactoring is the process of taking a running program and adding to its value, not by changing its behavior but by giving it more of these qualities that enable us to continue developing at speed.” – Kent Beck

A new developer gets his hands on an existing source code, and soon your hear this complaint : “Code is a mess, it must be refactored !” Sometimes, that’s true, and some other times, that’s a great recipe to end up with a code as bad as – or even worse than – the initial code. To decide if a refactoring is required, here are ten questions you should ask yourself (or the developer asking for the refactoring):

1. Why should this code be modified ? Seems obvious, but if the answer is “because it’s ugly”, that’s a bad start. As much as you may hate a code with a “bad smell”, rewriting it just for the sake of elegance is not a good way to spend your time and company’s money. You should consider a refactoring only if it makes easier adding this new feature, or fixing this bug. As grandpa says : “If it ain’t broke, don’t fix it !”.
2. Is this code updated often enough to justify the refactoring cost ? An old, ugly code which is stable because it has been thoroughly tested throughout the years, and which is rarely modified shouldn’t be refactored just for the sake of it. The refactoring introduces its own usual development issues : cost underestimation, regression risks, etc.  Let’s say that keeping this code as is costs you 1 day each time you have to make an update. You estimate a 5 days refactoring will bring down the update cost to 1 hour. If you update this code every week, just go ahead. If it’s once a year, it’s probably not worth it.
3. Does everything break each time someone modifies this code ? Means the code is not simple and clear enough for someone to update it without unexpected side effects.
4. Is the developer doing the refactoring more skilled than the original author ? Refactoring may be required when one can’t easily understand the code. But if the refactorer isn’t any better than the initial coder, you’ll end up with a different solution, as difficult to understand as the first one. Worse, the refactorer could be less proficient than the initial coder…
5. Do you have a better understanding of the problem now than when the code was written ? To quote Einstein, “Everything should be made as simple as possible, but not simpler”. That’s exactly what refactoring is about. When having an incomplete understanding of a problem, the corresponding code may seem too complex. Once you’ll have refactored the code, you may realize that it was just as complex as required.
6. Do all developers complain about this code ? Good code is understandable by an average developer, it shouldn’t be written for geniuses, because geniuses are hard to find and costly. If all developers complain about some code, there certainly is something wrong with it that could justify a refactoring. If only one developer in your team complains, the problem may not be with the code but with the person.
7. Is maintenance cost increasing with time ? You may notice that the development cost increases with new features, that the rate of bugs found also increases with each delivery, that the rampup of new developers takes more and more time. All these are symptoms of code complexity, and could be attenuated by a refactoring.
8. Are code metrics indicating a problem ? While good metrics don’t tell you anything about the quality of the code, bad metrics usually indicate something wrong. Monitoring code metrics over time may help you identifying problems in code complexity that could be addressed by a refactoring.
9. Are there unit tests covering the existing code ? Refactoring is a great way to break things which work… Before starting it, you want to have some automated tests. If they are not available, schedule some time to write them, add this time to the cost of the refactoring, and check if it’s still meaningful to go on.
10. Does everyone impacted by the refactoring agree with it ? Refactoring introduces some risk. Everyone impacted by the refactoring should agree with it. For example, refactoring may double the work of your QA team, so you better make sure they are ready to take the load before doing the work.

Eventually, all these questions could be summarized in a single one :

“Is the cost of refactoring less than the cost of not refactoring ?”

Want to read more about refactoring ? Here are some good articles on the topic :

• http://sourcemaking.com/refactoring/when-should-you-refactor
• http://blog.codeclimate.com/blog/2014/01/09/when-is-it-time-to-refactor/
• https://www.simple-talk.com/blogs/2014/10/10/when-to-refactor-when-to-rewrite/
• http://programmer.97things.oreilly.com/wiki/index.php/Before_You_Refactor

Want to read even more about refactoring and get technical ? This is THE book to read :

• Martin Fowler : http://refactoring.com/