If there are so many usually undisputed benefits from well-structured, comprehensible
code, and if refactoring leads from chaotic, badly structured, error-prone code to well-de-
signed code by performing a series of small, controlled operations, why then every soft-
ware developer does not do refactoring?
Software developers are often reluctant, because some refactorings are simply tedious. And
there is no visible external benefit for all the labor put in.
Also management may be at fault. As long as management only rewards externally visible
code properties such as functionality and performance, but neglects to pay attention to the
code's inner quality, e.g. via code review or by failing to set coding standards, it is only to
blame itself, when software developers are reluctant to invest some of their precious time
on refactoring operations.
Then there is the serious risk of breaking the code through refactoring operations. And if
e.g. file-names change, traceability of modifications is likely to become an issue, too.
Even if the software developer is keen to refactor some badly structured code; his/her man-
ager, however, may have quite a different perspective. The manager may oppose any at-
tempt to modify working code. These concerns cannot simply be ignored, but must be suit-
ably addressed by both developers and management.
When doing refactoring; the externally observable behavior of your components must be
guaranteed to stay the same. If refactorings are carried out manually, one needs to fre-
quently rebuild the system and run tests. Manual refactoring is therefore not advisable.
Most IDEs offer good automated refactoring tools and they must be used.
When refactoring is done manually then lots of problems will be faced by the developer.
Manual refactoring by nature is tedious. It requires hours of precious development time, as
the developer has to make changes at a large number of places in the code and then has to
thoroughly check. Not many programmers would enjoy the task of renaming a method in
a large code base. A simple search and replace will potentially find extra results. So each
replacement must be examined by the programmer. At the same time, this repetitious and
boring work is definitely tedious. A refactoring tool therefore can save hours of work. At
the same time it guarantees that no bugs will be introduced in the code due to renaming or
The speed of automated tools has another benefit, which is shown in team development en-
vironments. A developer is much less likely to perform refactoring operations manually if