Review of “Refactoring at scale” by Maude Lemaire

My main area of expertise in my everyday work is actually cleaning 😉 And no, it’s not Tony Soprano style of cleaning, but working on making the codebase better. I really enjoy refactoring, applying good practices, and seeing Sonar stats going up. Therefore, when I saw the title ‘Refactoring at scale’ I was both interested and excited. Unfortunately – not for long.

Before I dive into the book, I need to clarify something. When it comes to books about good practices, refactoring, and such, we usually face two types of them. First one is a very well-known type, with titles like ‘Clean code’, ‘Refactoring: Improving the Design of Existing Code’ or ‘Working effectively with legacy code’. The most important aspect they describe, is low-level, code-altering techniques, that you can use right away. Let’s call them tactical-level books.

On the other hand, I’ve never had an opportunity to read the book, which looks at the process from a wider perspective. Refactoring methods applied on the class or method levels are important. What is more – it would be the best approach to apply them in our everyday work. Just when creating or updating the code, when we see a thing that can be improved – just do it. Scout-boys rule applied. That is the perfect world that I’m describing now.

Unfortunately, usually, in order to apply wide-range refactorings, we need something more. This ‘more’ is usually a human interaction process, where we convince our leads, managers, bosses or bosses of our bosses that we need to spend company’s money, in order to work on something that is already there. That’s how non-programmers see refactoring. As an ever-lasting, money burning process, that brings no palpable fruits. Am I wrong?

Judging by the cover (and table of contents of course), ‘Refactoring at scale’ seemed to be a perfect read, for all those people out there that want to refactor bigger things, and have to sell this idea. I was hoping that after reading it, I would be armored against all the possible contra-arguments for refactoring. Wielding magical weapons of knowledge and understanding, why bigger refactoring is needed. Have I succeeded? Nope. I was killed and eaten by the goblins, before I reached the dragon’s cave.

In short – in my opinion, the book promises a lot. Unfortunately, it does not deliver. We get clearly separated parts, where chapters are written in order to describe every step along the way, of performing an actual ‘refactoring at scale’. From identifying the problem, gathering metrics, convincing people and assembling a team, to delivering refactoring we want. However, I find it just talk, talk, and even more talk. I understand that the authors needed to describe the environment in which refactoring is happening. They needed to present a step-by-step procedure. Unfortunately, the actual knowledge on how to do these things is not there.

From my perspective, it would be great that in every chapter, after presenting the discussed topic, and laying out what we want to achieve or do, add at least a couple of pages, presenting actual live samples at work. E.g. When discussing metrics that we can use to gather about the project, present a sample of such a process (saying that ‘there are solutions for that’ does not cut it). When writing about convincing your boss about the need for refactoring, add a made up discussion, between the boss and the developer. Building on the knowledge (or the aforementioned metrics) gathered in previous chapters. When discussing team organisation, and motivating it – create a virtual team of people, and present actual
approaches we can use for stereotypical team members (eager junior, cautious introvert, seasoned and burned-out senior developer).

It’s possible that I’m biased. I’ve been around refactoring and making code better for some time now. I’ve read/listened/watched tons of materials about the process. Therefore, maybe this book is not for me. Maybe it’s great entry material for people just getting to explore the topic. However, from my perspective – ‘Refactoring at scale’ was a waste of time. Luckily, the book is not long, so I was able to finish it fast. If you’re interested in reading it – please take your experience in the area of refactoring under consideration. If you’re new to the topic – go ahead, I think you can benefit from the read. However, if you’re a seasoned refactorer – try to find some more appropriate source.