Agile FUD: Frequent refactoring

This post is part of a series in which I address Bill Miller’s criticisms of agile. Please read the original post for context. In this post I take on his criticism of the role of documentation in the agile process.
Bill Miller says of refactoring:

The mantra in the Agile community is constantly refactor. This is a highly expensive approach, and in this age of globalization where costs drive decisions, it should be looked at with trepidation. This isn’t a wise approach, as market pressures to deliver quickly always constrain your latitude for refactoring.

Let’s look at one of the agile projects that I’m currently involved with.


It’s a typical multi-tier Java-based web application. In a waterfall-type environment, we would work from the bottom up: complete the data access layer, then the business logic and finally, the user interface. In that environment, if you get something wrong in your implementation of the earlier stages, you end up repeating the mistake and having to fix all instances of the mistake.
In our project, we’ve adopted the vertical slice methodology. We develop one small part of the entire application at a time. Just as much data access layer and business logic as we need to support a little bit of user functionality. In the process, we identify a lot of unknowns and can refactor things only for that small set of functionality. Also, this allows us to implement future slices much faster, as we’ve already worked through many of the issues.
To be fair, we sometimes face the need for an entire supporting service, and therefore in some instances, we do indeed have to implement a complete chunk before we can do the vertical slice. But so far, this process has worked quite well for us. And the bonus is that you have a working slice of the application that you can show management and customers.

One thought on “Agile FUD: Frequent refactoring”

  1. I’d also say that if you’re conscientious about building your test suite, refactoring is not terribly expensive, and it can certainly save huge amounts of time later when you’re trying to find bugs in code that actually makes sense instead of the junk you wind up with if you eschew refactoring.

Comments are closed.