Rating:

I’m not quite sure what to think of this one. The book is quite short and can be divided into two parts:

The first part consists of a few ’tidying’, which really are tiny refactorings. The idea is that you shouldn’t start big refactorings, but improve code little by little. The upside with this approach is that you don’t need to plan it, and that the risk of going into an unfortunate direction remains minimal for each step.

The second part consists of a theory where, in essence, the author argues about whether and when you should apply the ’tidyings':

The rest of the book goes into more detail and weights the two options, answering the question ‘Tidy first?’, or, whether to tidy or not (and whether to do it first, but other times such as ’later’ are discussed as well). There is, of course, a lot more detail and examples of when the decision is a clear-cut and when it isn’t.

I, personally, am unsure what to make of this theory. It certainly has a point, but I disagree in some situations:

For experienced developers, the first part about ’tidying’ is not going to contain anything new, or even interesting. The second part is nice to think about, but as I mentioned previously, in my very personal opinion, not without some flaws (your opinions may vary.).

Fresh developers could profit from the first ’tidyings’ part of the book, but are probably not going to be able to relate too much to the second part.

So I’m not sure whom to recommend this book to.

The author also mentioned that this book is only the first of a series, related to the things that a single developer can do (small ’tidyings’). Maybe my points will be cleared by a future release.