Agile 101 – Refactoring Agile Code

Refactoring in agile processes seems like a two-edged sword. If it works, and all functionality remains, then that's great. But then again, I question the benefit. See what you think.

In any documented project management processes, there are implied, or specifically stated, priorities. It seems that refactoring could work against those priorities.

More noticeably, it seems that refactoring works against the idea of 80:20 thinking, where you work on the things that get the most results. Tinkering with older code, and trying to perfect it, does not seem like an activity that is part of the 20% that gets 80% of the results.

But read the post, and decide for yourself.

Here's the TenStep post on "Refactoring Agile Code".

In a traditional development project there is a tendency for one person to write entire programs to implement certain functionality. It is likely that once a program or component has been written and tested, it will never have to be updated again during the project. 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 he 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.” This is considered a more cost effective approach. 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 the code tends to break or that errors are introduced whenever this old code is touched.

Agile projects take the opposite view. If a subsequent Developer has concerns about the way a component is coded, or if he thinks the code is not as efficient as it needs to be, the second Developer takes the time to update the code. This constant review and modification of code is called “refactoring.”

Refactoring is the expected practice of continually updating prior code if the current Developer thinks that the code can be improved, better documented, or optimized. Refactoring may or may not take a little more time to write and test during the current iteration. The greatest danger of touching old code is 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.


Refactoring is one of the philosophies that are unique to Agile. It is not just something you do if you see a major problem. It is a mindset that you have whenever you make changes to an existing component. When traditional project teams may shy away from the practice, Agile teams embrace it. The result is the ability of Agile teams to maintain more flexible and efficient solutions all the way through the Agile project.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>