Book Review: 99 Bottles of OOP

Book cover 99 bottles of OOP
It's only fair to share...Share on Google+0Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Email this to someone

This time around, I decided to give you my comments on a book I recently read – or at least partially read since it is not finished yet.

99 Bottles of OOP is an amazing work from well-known Sandi Metz in cooperation with Katrina Owens (creator of exercism.io). Currently, the book consists of 5 of the planned 6 chapters with the last one hopefully arriving soon.

Let’s bring a bit of structure into this review. I will provide you with my views regarding the following topics:

  • Content – what is this book about
  • Intended audience – who should read the book
  • Style – easy reading or deep thoughts required
  • Summary – what is it that makes this book stand out

Content

The premise of the book sounds as simple as ridiculous: It’s all about how to implement the 99 bottles of beer song. Yes, one very repetitive song, spread out over many many pages. While I was sceptical about this at first I heard many good things about the book and I can tell you: it works.

The book starts with requesting the reader to first implement a solution and then start diving into the book. Several potential solutions are presented. Most of them rather shabby, some less so. One that forms the basis for the remainder of the book is referred to as “Shameless Green”. And it is basically what most people would refer to as a quick&dirty solution. It works, it doesn’t have major flaws, but it certainly isn’t a good basis to continue building upon.

The second section takes a look at TDD as a structured approach to arrive at solutions. After initially presenting the finished solutions, this section shows how you end up with the “Shameless Green” solution by only following standard TDD practices.

Starting with section 3, things get more interesting. A requirement change is introduced, which serves as the need to make improvements to the code. I particularly like this part, since I teach that in my Clean Code courses as well: Don’t just improve your code for the sake of it, wait until you have a proper reason to do so.

So Sandi and Katrina start describing how to get to an improved solution, and here comes my main takeaway of this book and why I can whole-heartedly recommend it: the Flocking Rules.

The flocking rules are simple to write down, but it takes a few dozen pages of reading on, until you may actually grasp their power. The flocking rules as given in the book are:

  1. Select the things that are most alike.
  2. Find the smallest difference between them.
  3. Make the simplest change that will remove the difference.

These simple rules, applied over and over, lead you towards better code. The premise of the authors is that you do not even need to know how better code looks like. Applying these rules automatically gets you there. It’s a strong hypothesis and personally I think it’s phrased rather provocative and would probably not hold up to empirical evaluation. Nevertheless, you should not underestimate the power hiding in the flocking rules. While I doubt that they will work every single time without you having to know what you’re doing, basically, they are extremely valuable.

What’s really interesting is the reversal of the traditional notion of DRY. Developers look for an existing duplication and try to get rid of it. But with the flocking rules, you instead work towards a duplication and only then do you address it. This should come as second nature to experienced developers, but unless you haven’t yet reflected much on how you do get to see these duplications, following these rules will make you a much better developer.

In section 4, the authors discuss horizontal refactoring. Generally, when people refactor, they do not pay attention to their destination. It takes awareness and discipline to do horizontal refactoring, which essentially means, staying on track towards your desired destination. If you jump from refactoring one concept into the next, you complicate things tremendously. Horizontal refactoring is a way of managing complexity and to avoid getting side-tracked. Sandi and Katrina manage with numerous examples to explain this really well and I wish I had read this earlier. Unfortunately, I had to learn this the hard way, when several times my refactoring efforts have run along all axes only to end up in a mess that had to be reverted. After the reversal, I basically restarted with a horizontal refactoring – doing one thing only, staying on track until it is completed, and only then start addressing the next one. Doing it in this fashion in the first place is certainly saving you some sweat.

The fifth section looks at responsibilities. It is basically a whole section about the single-responsibility principle. Again littered with different examples of different levels where this principle applies. It’s an important section, but one of the less interesting for developers already well aware of the SRP.

The last section, which has not been published yet at the time of this writing, will deal with replacing conditionals. I’m really looking forward to this, since for the past year I have also focused a lot on getting rid of conditionals. I found my code ending up much simpler without those pesky conditionals and I’m very confident, that this section will have a strong impact on its readers. It is one of these topics, where the newbie developer gets shown a new horizon and some veterans may even oppose it. I have come across many a developer claiming that this or that conditional is absolutely necessary, but almost every time it isn’t. It just adds unnecessary complexity.

Intended Audience

I think the authors did a good job explaining that this book is particularly useful for someone new to object-oriented programming. Apart from the actual content, the examples and explanations place a strong emphasis on transporting the essence of OO to the reader (and I’m talking Smalltalk-like essence, not Java-like here).

The examples in the book are all in Ruby, but frankly, it doesn’t matter at all. I haven’t done much with Ruby, but gladly Sandi and Katrina managed to keep the content independent of Ruby-particularities very well. You can easily follow it with just basic knowledge from any other OO language as well.

Similarly, they explain that veteran developers may have a hard time with the book. Personally, as I’m teaching Clean Code I found no trouble whatsoever with understanding the content. It actually discusses a lot of the clean code principles – in fact it is so close to it that I am considering incorporating it into my trainings. I’ll have to contact Sandi and Katrina about that and see where it goes. But from my own trainings, I can second that observation: sometimes experienced developers have trouble to accept these principles. They go against all they have learned and done for a decade and longer, and we all know just how hard un-learning things can be.

Style

This is the only point where I have minor problems with the book. It is generally written in a style that is easy to digest, which suits the topic. However, the authors often hammer a point home again and again. In an ironic way, the authors remove code duplication whilst adding duplicated explanations. There was a paragraph every few pages which to me appeared pure noise, without any new signal or value. It may help to get the point across better to some readers, but to me, it felt unnecessary. Almost like a minimum number of pages had to be filled up.

Other than that though, the book manages really well to demonstrate a fine point that I always struggle to pass on to participants in my courses. Once you start applying these principles and massage your codebase, small pieces of work start building on top of each other. What may seem like just a minor improvement almost not worth the effort will later-on be in perfect shape for the next such improvement. I often experienced this first-hand, but it is hard to explain it to someone who hasn’t. I believe the authors did a fine job there, though probably only someone who hasn’t been aware of this effect can really judge that.

Summary

Despite the minor style problem, which may not be much of a problem to other readers, this book is a true gem. Whether you are new to development, or already a veteran, there is so much in there (already!) that makes it certainly worthy of purchase. This is one of the rare books that I can recommend to pretty much everyone at every level.

It is amazing how far one can go starting from that trivial song and even more amazing that the authors managed to make you wish for the book to keep going.

It's only fair to share...Share on Google+0Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Email this to someone