Agile 101 – Refactoring

Agile 101 – Refactoring

In a traditional IT development project there is a tendency for one person to write entire programs to implement certain functionality. A developer tends to own the code that she writes. 

This is not the case with an Agile project.   Agile projects build incremental solutions over time. It is very possible, and perhaps likely, that a component that was written to support a specific piece of functionality may need to be updated later with the introduction of some other use case with related functionality.

On an Agile project when the second developer works on a module that another developer worked on previously, a couple things need to happen. First, the second developer needs to review and understand the work of the prior developer. Second, the second developer needs to insert new and revised code to support the new functionality.

When the second developer reviews the code, it is possible that she may have some ideas to make the code more efficient or easier to support. In a traditional project, there is a tendency to leave this inefficient code in place. The thought is that “if the code is not broken don’t fix it.” Therefore, prior code that seems to be working tends to be isolated so that new changes do not impact it. This approach usually results in code that becomes very “brittle” over time. “Brittle” means that developers don’t understand how the code works, and that errors are introduced whenever this old code is touched.

Agile projects take the opposite view. If a second developer has better ideas about the way a component is coded, the second developer takes the time to update the code. This constant review and modification of code is called “refactoring.” Refactoring is the continuous practice of updating prior code so that it is improved, better documented and optimized.

Refactoring may take more time to write and test during the current iteration. The greatest danger of touching old code is still that you will break something that works today. However, this risk is minimized on Agile projects by automated and rigorous testing so that any new errors can be quickly discovered and fixed. Any short-term impact is offset by continually delivering better and better code over the life of the project. The code will be cleaner, more efficient, more flexible, better documented and much easier to support longer term. The result is the ability of Agile teams to maintain more flexible and efficient solutions over the life of the product.