A while ago, an ex-colleague of mine shared with me he had been given a task to refactor an enormous legacy MS SQL stored procedure. It was interesting to me how enthusiastic and happy he was without realizing the upcoming pain… Well, two weeks later the “refactor” was not even close to the final goal and management gave him another task because they had realized that this one is a lost cause. Is he a bad developer? Not at all! Only the approach for that refactoring was wrong. Let us recall what does “refactoring” mean? Refactoring is the change of the internal structures…

If we look into Wikipedia for code refactoring, we are going to see the following: “Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes) while preserving the functionality of the software.” Why code refactoring? Why do we care about improving the design, structure, and/or implementation of software? From the project manager’s point of view, the goal is to reduce the cost of support and future development. That is fine, but what makes the regular developer do refactoring?…