Why Shouldn’t I Call Rework Refactoring?
Recently I have noticed a disturbing trend to use the work “refactoring” when doing “rework.” Confusing the two words is more than just semantic faux pas and occasionally stinks of spin. Both words have fairly standard definitions that provide a basis for use. I posit a set of working definitions for the two terms are as follows:
Refactoring: modifying without changing the external behavior of code or other work products. Refactoring neither fixes bugs nor adds new functionality (Wikipedia).
Rework: modifying work products by correcting defects found during reviews, testing or inspection meetings. Rework fixes bugs and can add new functionality (missed requirements).
I deem using the word refactoring to cover rework disturbing because refactoring is a process of increasing efficiency and effectiveness through simplification. Another way to think of refactoring is process to deliver code / solution in a manner to paraphrase Albert Einstein, that should be as simple as possible, but no simpler. Rework is fixing the mistakes / defects that have been injected during the process. Rework is effort that needs to be avoided by avoiding defects while refactoring is work that should be embraced. One could argue why not create things as simple as possible out of the gate but understanding, knowledge and tool usage evolve therefore providing an opportunity for improvement.
I would suggest that organizations make every effort to provide transparency into their processes by using words that illuminate how they are spending their effort and money and less on obscuring process issues that are correctable. Both rework and refactoring are important in developing any work product but they are different.
