9 Reasons to Read 99 Bottles of OOP 2nd Edition

What makes code “good”?

Writing good code is hard, and quantifying what makes code good is even harder. A few of the common descriptions used to quantify good code are:

• Doesn’t have duplication
• Uses “abstractions”
• Follows SOLID Principles
• Is concise
• Has 100% test coverage

We learn these concepts at our jobs, in books, and in online forums, but what do they all actually mean? How can we put these principles into practice, and are they even valid metrics of good code?

99 Bottles of OOP answers all of these important questions.

The Breakdown

99 Bottles of OOP (99 BOOP), written by Sandi Metz, Katrina Owen, and TJ Stankus, centers around writing a program to output the lyrics of the timeless tune “99 Bottles of Beer.” In the introduction, the reader is asked to take 30 minutes to write their own implementation of this challenge. After solving the problem, the book dives into comparing the merits and disadvantages of different solutions. From there, the authors add features to the code, guiding the reader from simplicity to flexibility, while evaluating “When is code good enough?” at every step of the journey.

99 BOOP draws from expert literature in software design, utilizing concepts from the most influential OOP books over the last twenty years. These books include Design Patterns: Elements of Reusable Object-Oriented Software and Refactoring by Martin Fowler. The authors analyze and apply patterns from these books, turning them into concepts that are easily consumable and enjoyable to read.

Why you should read this book

1. Details A Prescribed Refactoring Process

One of the most important concepts the authors convey is to make refactoring changes only one line at a time, while running tests after each change. While the process is tedious at first, the rigor gained from following this pattern instills a huge amount of confidence in the final code. Learn how to follow “Flocking rules”; identifying what parts of your code are the most alike, and then removing the biggest difference between them.

2. Provides Measurable Code Metrics

Since there aren’t many ways to measure the quality of code, the authors present what is available, explaining their pros and cons, and how we can use these metrics as guardrails when determining between multiple implementations of requirements.

3. Teaches Cost Effective Refactoring

99 BOOP states that refactoring should never happen prematurely, and the optimization of code shouldn’t be based on assumptions around future requirements. Instead, new requirements should be the deciding factor around changing existing code, using these requirements as permission to start making small refactorings.

4. Learn What and When to Test

Sometimes it isn’t clear what to test, or even if something should be tested. When refactoring, is it important to add tests before or after extracting code? 99 BOOP explores answers to these testing questions, with two chapters dedicated specifically for writing meaningful tests.

5. To Understand the SOLID Principles

The advocacy for the use of SOLID principles is widespread throughout software development. If you have ever read this Wikipedia article, you may have stopped once you got to the confusing definition for the “Liskov substitution principle”. The formal definition states:

Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T.

Luckily, 99 BOOP presents unique definitions for the SOLID principles, which are more understandable than the example above.

(A talk by Sandi Metz, is actually a reference on the SOLID Wikipedia page)

6. How to Derive Abstractions Late

As a developer, I am drawn to abstraction. However, abstractions have a tendency to deteriorate. 99 BOOP believes that this problem lies in trying to extract these abstractions before they are necessary. The authors conclude that we should wait until abstractions make themselves known to us, instead of prematurely making code more abstract.

7. Makes an Argument for Simplicity

Short and compact code isn’t always best. Instead, Sandi and Co. state that simple and readable code, albeit lengthier, communicates more clearly to others and our future self.

8. Sometimes WET is better than DRY

DRY is an acronym meaing “Don’t Repeat Yourself”, conveying the idea that a snippet of code shouldn’t be written more than once. In Dan Abaramov’s recent talk, “The WET Codebase”, he chronicles how a decision to extract common functionality led to an unruly mess. As the codebase progressed, he found that this common code was not exactly the same, and corrections to this new shared dependency created bugs - ultimately becoming unmanageable. No one knew what it was supposed to do anymore, so no one wanted to try and fix it. 99 BOOP expresses how duplication isn’t always bad, and can even lead to more clarity as the use cases are more explicitly defined where the code is used.

9. Answers when “Good” is Good Enough

99 BOOP helps you create your own mental model for what makes code good. This doesn’t always mean short code, code that doesn’t repeat itself, or code that utilizes many abstractions. If you want to build a vocabulary around code quality that you can use when communicating with other developers, I recommend reading 99 Bottles of OOP.

Get the book here! https://sandimetz.com/99bottles