If the Code’s Good But Not Perfect Code, Plan to Refactor

This is the sixth in a series of posts on dealing with the impediments raised in “Agile Antipatterns Are Easy to Spot, Hard to Change”. The sixth antipattern discussed in the post is…

6. Postponing refactoring until later, usually after a release

Software refactoring is one of the most misunderstood and controversial aspects of agile development. Perhaps it’s simply because if we wrote perfect source code from the beginning, there wouldn’t be a need for refactoring. I can’t speak for you but I know that I’ve never written perfect code in a single pass and I don’t know anyone who has.

So is refactoring a euphemism for fixing mistakes? Yes and no. This is where it gets blurry.

Fixing reported defects is not refactoring. If the code is wrong, it needs to be corrected. However, the definition of defect is often complex. At times, what one person observes as a defect, another observes as a feature. Regardless, if the Product Owner decides it’s a defect, just fix it.

If the software is too slow in responding to user inputs, is that a defect? What if the software consumes too much memory space? Those are tough questions to answer and tend to be situational. It’s up to the Product Owner and the team to decide what action to take, if any.

We still don’t have a clear definition of refactoring. Let’s try this simple perspective:

Refactoring affects the internal operation of the software. It does not affect the externally observed behavior.

Here’s an analogy. I could upgrade the processor, the memory or the hard drive in my computer without any changes to the way I interact with it. In a sense, I’d be refactoring my system — making it better.

However, if I patch the operating system to correct a problem, upgrade the keyboard for better ergonomics, or buy a larger display, I’m not refactoring. The first fixes a defect and the other two change the behavior of the system.

Should you try to avoid refactoring?

No! In fact, do the opposite. Plan to refactor. Allocate time for it. Don’t aim for perfection on the initial implementation of any code module. Get the software up and running quickly, even going as far as cutting a few corners. Once you know that the implementation is what the users want and need, refactor to make the code lightning fast, efficient and maintainable.

Refactoring is an important part of the team’s frequent delivery and continuous improvement efforts. Embrace it.

Updated: November 20, 2011 — 10:33 pm

1 Comment

Comments are closed.