ITWorld recently published an article about a study claiming refactoring usually doesn’t result in improved code quality. The authors of the study say “Even though some of those studies claim that refactoring improves the quality of software, most of them did not provide quantitative evidence”
There are other claims in the study that are a little concerning — refactoring doesn’t make code easier to change, doesn’t make code run faster, and refactored code isn’t more resource efficient.
My first instinct is to question the premise and techniques of the study.
But, does the study even matter?
This study was determining changes in code quality through data returned by a static code analyzer. Changes in things like cyclomatic complexity, number of lines of code, class coupling, and inheritance depth were used to make assumptions about how much the code quality had improved.
This feels like a really narrow definition of quality and it definitely ignores a number of other reasons — understandability and maintainability for example — that a person might chose to refactor a bit of code.
Why Do We Refactor
Robert C. Martin (Uncle Bob) has an entire book dedicated to refactoring titled Clean Code. The book steps through real examples naming methods, simplifying complex code, testing, and test driven development (TDD). Never once does he mention how to measure if your refactoring efforts were worth while, or if you were actually improving code quality.
In the book, Bob talks about working to make your code better as if it were a virtue or something you do because not doing it is stupid. Like flossing your teeth every day. You won’t automatically get a cavity because you aren’t flossing everyday, but picking up the practice will probably lower your chances.
Bad code is something that slowly creeps in.
Code refactoring is most often thought of as something performed by and for programmers, but ultimately it is a business decision.
There is a cost and time trade off involved. I could develop this feature and be done with it in a day, or I could add another half day to improve the code I’m interacting with. There is a gamble, spoken or unspoken, that delaying feature development a little bit is worthwhile because because maybe it will be faster in the future with the changes you’ve made.
What About The Other Stuff
Refactoring is a technique for making improvements in the same way that design techniques like Test Driven Development (TDD), process philosophies like agile and lean, and These are concrete improvements that relate to financial benefit for the business. Most of these methods have a bad name to some extent in some circles. TDD apparently died last year, and agile is well on its way to becoming a way for people to make money off of selling certifications.
All this because people learn about a method and apply it indiscriminately.
It is no surprise that refactoring doesn’t often result in increased performance or less measurable coupling or lower cyclomatic complexity in software. Refactoring changes are often small enough that they may not make a noticeable difference in the output from a static analyzer. Also, bigger, more visible, changes tend to get checked in under the name of technical debt.
The study and the results of the study might be flawed, but there is a valuable lesson hidden in there about the value of our work.
I’m confident that one study on a small sample won’t stop people from striving to make their code better.