Refactoring

The software has its live cycle during which the development and bug fixing are link to several variables, some under control or the developer but many are out of this control. I'm not talking much about the time dedicated to the development during a project, but too. Those variables are out of control specially in the bug fixing time, when the speed and extreme programming are more present.

When some day, some how, some one decides that something is urgent, or more urgent than the other urgent things. At that time, the development will done because of an heroic effort and all bugs will be fixed fast (hopping that the bug fix will not produce any other side effect).

How old must be a code to consider refactoring? It could depend on the number of requirements coming from the heaven. I mean when the number of times that some one is very urgent to codify, the developer does it, but with a price. And this price is a quality loss, until it becomes untenable. When any bug fix requires longer and longer time due to the side effects of the modification.

But there is a moment, that triggers an alert for the project manager that says refactoring is mandatory: when the design have almost nothing in common with the code: when code smell.

Then I found a book that looks nice for this task: "Refactoring: Improving the Design of Existing Code" Fowler, Martin (1999). More than ten years old book, older than the code I want to refactor, live irony.