• (hreview version 0.2)
• (Reviewed on 22 October 2008 by Anthony Bailey)
• product

This book concerns the detailed choices we make minute-to-minute when implementing programs.

The first twenty pages express Beck's context and motivation in his usual fashion: some personal history and philosophy, some thoughts on cost, and a prioritized set of values (communication, simplicity and flexibility) and some principles (DRYness, symmetry, preferring declarative to procedural expression, plus three ways to group things that change together) that help in translating those values into specific practices or patterns.

The next hundred pages is a catalog of seventy-seven such patterns.

Two closing chapters offer an overview of collections, and sketch some ideas of how things change if you're coding a framework rather than a specific application.

---

I think those first twenty pages are excellent. Two of my previous favorite books by Beck outlined a core precept, asked "what if we run with it?", then detailed how to extract far more value than you might initially expect. (To over-simplify: XP Explained follows from keeping the cost-of-change curve as flat as possible, Test-Driven Development follows from a belief that making code testable improves its design.)

The main idea in Implementation Patterns is that making code readable is key in good implementation, and that turning those dials to eleven will provide similar unexpected insight. (For example: given that a good name for a variable describes its role in context, then if all good names seem long, you're probably missing an abstraction of context - i.e. there's a class waiting to be extracted.) Not quite as big an idea as in the other two books, but very plausible, and my appetite was whetted for the patterns where I hoped this idea, and all the values and principles, would be explored and discussed in context.

Alas, no. I was very disappointed. (The above was about the only example I could find.) There was very little exploration and discussion, and the patterns did not often refer back to the values and principles, even implicitly.

OK, since it doesn't build sufficiently on the introduction's abstractions, the meat of the book had better work well as a stand-alone catalog of patterns.

Alas, a second no. One of the useful things explicit lists of patterns do is to give a name to a concept so we can communicate about it. Beck's list does do this useful thing. But, that is about the only useful thing it does. Once named, there is rarely additional insight in the pattern descriptions: they mostly do exactly what they say on the tin. You can read the table of contents to see how simple the concepts under discussion are.

The last two chapters are fine, but unremarkable.

---

My recommendation: borrow the book to read the material preceding the catalog. Then buy and read Clean Code.