Developers: please stop using the term ‘Refactor’ if you do not run a good suite of automated unit tests before and after the change
Without the safety net of automated testing, it is just ‘code changing’, not ‘code refactoring’.
I expressed this view (as the title) in a project meeting many years ago, and I regretted it. Why? The statement is correct, based on the definition of Code Refactoring. However, it did no good to my relationship with the other developers in the team simply because they did not understand, and I was not in a position to influence them.
The Story
About 16 years ago, I left the position as a Lead Developer (in Java) and joined a large .NET project for two reasons:
learn a new technology/language
influenced by the classic Pragmatic Programmer book, to try a different languageget better pay
there was no shame in admitting that, as a contractor programmer and the sole bread earner of the family.
There were many issues with the software development practices in this new project. For example, a configuration engineer (who managed the building of the software) once claimed excitedly: “It compiled!”. The project lead (i.e. PM), who worked with me on the last project, grinned and commented in a low tone: “It is so sad”.
Later, the PM called all engineers for a meeting to improve the process. Prior to the meeting, I reminded myself to keep quiet. The meeting was quite open. As usual, the developers who had been with the project for a long time talked mostly. They used the term “code refactoring” a lot. When the PM looked at me encouragingly, I felt I needed to say something. Therefore, I commented: “We are not doing code refactoring as we have only 4% unit testing coverage. We just make code changes, not refactoring”. The meeting went into dead silence. The PM wisely wrapped up the meeting.
Except for the configuration engineer (I showed him before the meeting), the team members didn’t even know that we had 4% unit testing coverage and that 4% was pretty much all done by me.
The Dilemma
At that time, Refactoring was a cool term to use, and most people tended to agree that “Good programmers write unit tests”. However, most developers did not know how to write good unit tests, or proper refactoring techniques. I did not belittle my colleagues in that project, I only learned these skills (by pair-programming with a world-renowned programmer for 6 weeks) a year ago.
Those engineers all had an attempt at writing unit tests though not seriously. An example was that they wrote a few (that easy to write) and ran them spontaneously. This gave them the feeling that they were ‘good programmers’ and they did unit testing. However, a developer won’t run these unit tests (even for the ones created by one developer) again, and as a result, before long, a large percentage of those tests would fail. In other words, these developers lack the maintenance mindset for unit tests.
When I presented the correct (obviously) method: running all unit tests with objective code coverage stats before and after my code changes, i.e. refactoring, they were shocked.
Some developers might think: “It is hard to write unit tests for some code and maintaining the whole suite of unit tests seems impossible”. I largely agree. However, this does not change the fact “Refactoring is based on solid unit testing”. The general lacking unit testing capability is common, it is an individual programmer’s fault. The failure of IT education is to blame. I did not see real unit testing after I programmed ‘professionally’ in a senior role for 7 years. In my opinion, the only practical way is to learn from an expert. In terms of how, I recommend ‘Pair-Programming’.
My dilemma was that I was not in a position (job title) to influence them. By the way, this is a thank-you message from a software engineer I mentored who later joined Google as a product manager.
He used these techniques I taught him (as a matter of fact, I only passed the knowledge I had learned) in his previous roles at Amazon and Microsoft.
Sadly, few developers are open-minded and willing to learn proactively like him.
Disclaimer: I no longer coach others (except my children) on coding, unit testing and refactoring, since 2011. My work focus has changed, I do software development at-home, and offer services only on E2E Test Automation and Continuous Testing.
Further reading: