Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated May 24, 2010 — Enterprise Agile Planning expert

Refactoring: You keep using that word...

Enterprise Agile Planning
One of the more powerful, yet more easily misunderstood XP tools is the practice of refactoring. It is actually such an important piece of the Agile development puzzle that most teams, whether they are actually doing Scrum or XP or Lean, or any other Agile process, tend to work toward adopting some form of refactoring. But what does refactoring really mean? When I'm working with development teams, I often will hear some phrases like "that is going to require a major refactoring." The implication here is that the software needs enough major redesign and retooling that it will take a considerable amount of time. This is not what refactoring was meant to be, and it is a disservice to yourself to think of it as such. As Martin Fowler first explained: "Refactoring is a process of changing a software system in such a way that is does not alter the external behavior of the code yet improves its internal structure". This is done through disciplined, small steps. There is a common theme in application development that we will design a system to the best of our ability, then some day when we have the time we will clean up any loose ends that appeared along the way. With refactoring, we do this clean up all the time. Every time I am in the code base, for some reason or other, I look at the area I am in, and see if there is some small refactoring that needs to be done. I use the entire box of agile tools available to me, most specifically automated unit tests. The refactoring, with the tests around it, shouldn't take more than a few extra minutes. The results may not be earth shattering but if everyone is doing this all the time, the whole becomes much greater than the sum of its parts. Which brings me to why I think folks are misusing the word refactoring. When I talk to programmers, they say they need to do major refactoring, by which they really mean redesign or rewrite. Call it what it is. Refactoring makes it sound less scary, and less drastic. Sometimes a rewrite might be necessary, but I'd be willing to bet that if you are following agile development practices, it is far less often than you thought. On the other side of the coin, I hear folks say "We do scrum. While we are doing our story planning, we need to account for a story or some tasks for refactoring." We don't need a story for this any more than we need a story for writing a "for loop" or fixing the spelling in a user document. If it's going to take so much time that you need to account for it in your schedule, it isn't refactoring, its redesign. And I bet you don't really need to do it.

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us