Of the original Agile 17, few have been able to match the clout and influence of juggernaut Developer Martin Fowler. Born and raised in Walsall, England  — so no, not that bloke from EastEnders — Fowler moved to Massachusetts in 1994 after obtaining a bachelor’s degree in Electronic Engineering and Computer Science. From there, just five years later, he published his book Refactoring, a detailed description of an indispensable process that would make a colossal impact on the world of Software development, particularly in the field of web development.

The rest is history, as for many moons now, Refactoring has served to educate, inform, and embolden generations of younger developers. Remarkably, however, the author has recently updated his book with a brand new second edition which reflects on the last twenty years and aims to clarify the topic further. So for today’s post, Software Planet is celebrating the book launch by bringing you up to speed!

What It Is

While many articles have been written on the subject, in a recent interview, Fowler described refactoring as a “change that doesn’t change the observable behaviour of the program, a purely internal change.” He went on to state that the purpose of these changes is to make the program both easy to understand and easier to follow.

 Of course, these alterations mentioned by Fowler refer to modifying a body of code. Yet though refactoring may be as simple as just renaming and reorganising classes, in many companies today, it is rarely used as aptly — or as frequently — as it certainly should.

What It Isn’t

If you’re still left scratching your head at this point, it is worth spending some time discussing what does not constitute refactoring. Above all, for instance, the key part of its definition is that these changes — however small — should always be “purely internal.” As a result, much in the same way that you cannot “refactor” a Word document, you wouldn’t refactor a program’s UI.

Or, stated in another way, this is never about fixing errors, making the code more testable, or even optimising software — it is simply about simplification. Your code should be as clean as is humanly possible to facilitate spotting code errors and make it easy to make changes should any be required in the future.

Advantages

But does this mean that refactoring is insignificant? Later in the interview, Fowler gives us his classic answer:

“These changes are so small that they’re not even worth doing,” he says and laughs. “But by stringing together a whole bunch of them, you can actually end up with a very big change.”

This point is a crucial one, as explained in a previous article, the main benefit of continuous refactoring is that it allows software developers to keep technical debt in check. Other advantages, however, include reduced code complexity, cheaper modifications, and improved maintainability.

Getting It Right

As one of the Extreme Programming techniques we have proudly adopted into this company, Software Planet believes refactoring should be a constant and iterative process. So with this in mind (and our unit testing in place), we do this by first making a small change, testing it to ensure correctness, and proceeding to move on to the following small alteration. Should, by the way, at any point a test fail, we undo the previous change and attempt it in a different way.

This also works extremely well when programming together in pairs, as two developers can refactor with much greater efficiency than one.

Conclusion

As a company of avid Agile developers, Software Planet Believes that along with all other XP practices, refactoring is indispensable to delivering outstanding products. For our customers especially, the practice is extremely important, as it allows us to improve their products as soon as any changes are needed.

Nonetheless, in the words of Fowler himself, even if you follow the right development process to a tee, “the biggest impact on successful development is motivated, talented developers.” 

Thankfully, at SPG, these too we have to spare.

Interesting Related Article: “How Is Low Code Development Changing the Software Industry?“