One characteristic that I consistently see among outstanding software developers is that they’re not afraid to change their minds, to change their approach, or to change their designs.

In Agile, we start building right away before we have all the requirements nailed down, and we let new requirements emerge as we’re building. To those unfamiliar with Agile, it may seem inefficient or even reckless to write code without seeing all of the requirements first. You wouldn’t build the first floor of a building without considering the rest of the structure. However, building software and building buildings are very different from each other.

New requirements can pull us in new directions and show us that our current design is inadequate. This is actually a good thing because we only want to build for what we currently know. So, what do we do when we know more? The answer is that we change our minds.

Refactoring is a disciplined way of changing your mind, of changing from one design to another design that’s more appropriate for your current situation. Refactorings are code transformations that let you safely go from one design to another design. This is how we should build software: through emerging designs as we go.

It was Martin Fowler who turned the idea of refactoring into a true discipline when he published his book, Refactoring: Improving the Design of Existing Code in 1999. This book is a catalog of code transformations that allow you to go from one design to another design and improve your code in some way without changing its behavior. Since its publication, Fowler’s book has become a critical resource for Agile developers.

The interesting thing about refactoring is that most refactorings are pretty straightforward and don’t require a lot of effort. Contrary to what some people believe, while refactoring legacy code may be difficult if it’s in a poor state, refactoring your own code from one design to another design is much easier.

This is important to note because it means we can change our minds and change our designs when we know more, and do it without paying a huge price. When developers understand this, it helps give us a level of freedom we hadn’t known before. No longer do we have to get it right the first time, which is an enormous stressor. We can start with a very simple design, and as we learn more we can refactor to a more appropriate design.

This turns out to be a highly efficient and effective way to build software. It not only builds software for the right purposes, it also helps us build software that’s flexible and able to change as new needs emerge.