This book is too terse and the flow of thought is disorganized and lack clarity; at time too vague to know what he is thinking. Also lacking is subsections that branch off from main section. This book is about some implementation practices at code level.
I hope the author can revised this book.

The book is about writing readeable/maintanable code. It's an interesting/important subject.

The first few (1-3) pharagraph is good , they clearly explain the values/principles of the topic.
Then the book tries to apply these pricnciples in a structured way - classes, state, behaviour, methods. This is ok, but there's too much repetition going on. And the examples are very small/specific, some more complex/longer examples would be much better.

Then there's 2 whole paragraph about the performance characteristics of various collections (map,hash,etc.), and the description of the framework used to benchmark them. I don't think it has to do anyhting with the topic of the book, and it was probably included to increase the number of pages (by 30 to 150).

Finally, there's also a chapter "Evlolving Frameworks" which is mostly about JUnit 3->4 improvements done by the author. It's an interesting chapter focusing mainly on compatibility issues related to framworks.

So i think this topic from this author would deserve a much better book.

I typically enjoy reading pattern's books and this is going to be one of my all-time favorites. This time Beck talks about patterns "in the small", not the traditional kind of architectural patterns we are used to know. This book it's about those small decisions we make every time we write even a small piece of code. Somebody could think the word "patterns" is misused here, but I tend to disagree and, in the end, I don't even care that much. What really matters to me is that I found valuable advice inside this book and I really enjoyed reading it. In the past Beck's books were always worth reading for me, this one benefit from a more fluid and pleasant writing style too.

Well written and organized, with a lot of short code fragments to illustrate the main points. However I have agree with the reviewer who suggested that this book should have been titled "Kent Beck on writing readable code". I'd add to this that the book is quite Java specific. Fine with me, but this needs to be pointed out. The book would have been more interesting to me if it documented the different approaches in use (along with their advantages and drawbacks) e.g. for choosing between checked and unchecked exceptions. Instead we get a few general statements about what exceptions are, and some suggestions along the lines of "low-level exceptions should be wrapped with high-level exceptions". The level of detail is often not enough to be interesting for somewhat experienced developers, but the book may be too abstract for beginners. Given the compact size of the book you'll still get good value for your time from reading it. Just don't set your expectations too high -- or expect to get good value for your money...

The right title should be something like... "Kent Beck on writing readable code". The word "pattern" is way out of context, and will induce you to expect to find something way more precise, detailed and technical than then general advice that this book has to offer. This text could be considered like a chance to have a chat with Kent Beck discussing his ideas on the importance of writing readable code, and on general guidelines for code clarity and expressiveness. I have seen a review complaining about using Java for the examples, but the truth is, you will see very little code in this book. I am also not very sure of the idea target reader for this work. An experienced programmer has already figured out this general advice by himself, but the level of abstraction and detail is too terse to be useful to a beginner. I believe that more material, more detail and a more tutorial-like style could have made this book a worthwhile read for a junior developer. As it is , I have to say it, but I have to rate it as a pretty useless book. I am a big fan of Kent Beck, I admire his programming style, his 'very good habits' and all his did with the XP movement. Together with Martin Fowler, and Allen Holub he's one of those guys who can really have a deep influence on the way you program and think about Object Oriented programming, but this time he' really been a bit self condescending. And the price.. come on..40 bucks for this? You should be ashamed...

The material that is there is good, there just is not much of it. It does contain the basics of writing good clean code, but the weight of the content just isn't there.

The book is kind of like this review.... to the point, but light on content.

I'd recommend buying the cheap PDF version and printing it yourself.

Just finished reading this book. Really enjoyed Kent Beck's short but precise and easy to follow through style and comments. Yes, as we develop software we seem to forget about the complexities we create and don't necessarily think about the "next" person whom may have to read the code that we write and extend as he/she sees fit.

Very clear point made at the start and at the end. We developers have to communicate better. So far in my profession, I have to maintain someone else's code as well, and as you may guess, it was not a pleasant experience, and I swear at times I rather had a root canal... :(

Anyway, great book. Read it! It has one typo that I scratched my hand for 30 seconds. The y-axis of Fig.9.2 on page 109 is missing. One can deduce it by looking at the subsequent figures, but since this is the first figure, I did not get it right away. Also coloring may be a better option since the lines are very close. I was also lost in "Performance Measurement" (last chapter), but it has been a long day, and probably my bad... And yes the points are made.

Overall enjoyed reading this book and definitely picked up some ideas and cemented down certain aspects of my development/design career. I think anyone, especially Java programming, would benefit by reading this book. Definitely recommend. Thanks, Kent. Cheers! - Baskin

If you consider yourself a senior Java/OO developer, you won't gain much insight here. I found that I skimmed almost the entire book in a couple hours. One issue I had with the book is that it seemed where the conversation got slightly interesting or may have more to offer, the text dried up and moved on, where it may have been well-served by a code example.

This isn't too say that Beck's patterns aren't useful or well-advised, but the interested buyer should understand if the book will be useful, and this really depends on your skill and experience. In general, I think we could all benefit if everyone wrote more readable, maintainable, and flexible code.

Pros: Gave me a tiny bit more insight into how a programmer I admire (Beck) thinks. Also the hand-drawn diagrams were intuitivie and easy to grasp.

Cons: Not much material. Book could have been half of its already short length. You sort of got the sense Beck was running out of things to say - the chapter on Collections has graphs of the running times of various collections, and an Appendix is devoted to the code used to create the graphs.

First, I'm not a Java fan, so using that as the basis for everything discussed left me cold from time to time. If the purpose of this book is to sell a philosophy of coding, why limit its audience to Java programmers?

On the other hand, if you know any OOP language, you should be able to follow most of this (having a Java book handy won't hurt!), so that's not a horrendous fault.

At times, I did feel a bit "talked down to", and I'm not convinced that Kent fully defended the underlying thesis that "good code matters". It matters to him, obviously, but does it matter to everyone? He says it should because we will spend less time on maintenance.. well, maybe, but I can point to thousands of hours of code where I've never done any maintenance, and have to wonder if the time saved with "sloppiness" there really is sucked away in the few cases where I come back for more work.. I'm not saying Kent is wrong, just that he hasn't proven his case.

So, defects: concentration of Java, pedantic, unproven case.

On the positive side, he's probably right, and it certainly isn't going to hurt anyone to think about his advice. Maybe it won't work for you, but some of it might be helpful and I can't see how it can hurt..

This is my first book review ever. I really enjoyed this book a lot I find the author to be a very principled man focusing on delivering value to his consumers. It saddens me to see that there many developers who do not see the value in what Kent Beck is trying to teach which exaplains why so much code is so difficult to maintain. If your looking for a book about advanced programming techniques, wizardry and hacks this book is definitely not for you. If on the other you want to learn write code that is useful to people then I can not think of a better place to start then with this book. The book is short but I think this follows the authors values of Communication and Simplicity.

Being a huge Kent Beck fan ..I pre ordered this book and was very excited to see what he had to say this time , but the excitement fizzled out only after a few chapters .
The book is about "back to basics " kind of topics and is extremely boring . You would have extremely hard time picking it back up once you put it down .
Pick up Fowler's Refactoring instead ( if you haven't already) if you are looking to improve your fundamentals .

I am a .NET developer but I have always liked books put out by Java developers because it seems they have paved the way in terms of agile practices and methodology.

This short read confirmed what I mostly knew already (and a few things that I didn't!), but you can never go wrong reading anything from Kent Beck or Martin Fowler. Sort of expensive book for being so small, but it was worth it.

Thanks Kent for another gem!

The reviews I've seen so far are bi-modal. Readers who were looking to communicate more effectively through their code found the book helpful. Readers who were looking for expert coding techniques were disappointed.

Kent Beck is like the Jonathan Livingston Seagull of programmers. When I read his writings or hear him speak, I can't help but think that he's been to some higher plane of programming and has come back to help the rest of us.

Implementation Patterns is his latest attempt to get the rest of us to think about more than what we are doing right here right now and to think about more than just ourselves. While some may not appreciate the author's philosophical approach to software development, I find it refreshing and challenging. He encourages us to look at our work as a contribution to society and not as just something we have to do to get a paycheck. He challenges us to think about others, those who will have to read and extend our code, and not just about ourselves. These principles are valuable in any occupation but are often overlooked in the technology fields.

Before I go too far and give the wrong impression, Implementation Patterns is not a philosophy book. It is a book about code, specifically Java code (one of it's strong points) with many useful ideas for writing better code. However, there is a philosophy behind these ideas and I believe that the philosophy is at least as valuable as the ideas themselves.

Now, on to the book.

The first two chapters, Introduction and Patterns, together serve as an introduction of just what the author has in mind when he refers to an "implementation pattern". This is especially helpful if you are familiar with the Gang of Four's Design Patterns book. This book does not follow the same format for describing implementation patterns as you might be used to with design patterns. Some patterns are described as code samples while others use the author's high tech modeling system.

The third chapter, A Theory of Programming, is my favorite. Here the author explains the ideas behind the patterns in the rest of the book. Here he talks about the values and principles that lead to the patterns. The values are Communication, Simplicity and Flexibility. The principles are Local Consequences, Minimize Repetition, Logic and Data Together, Symmetry, Declarative Expression and Rate of Change. The author describes the relationship between these elements, values, principles and patterns as follows: "The patterns describe what to do. The values provide motivation. The principles help translate motive into action."

Chapter four describes the motivation behind developing and using these implementation patterns. The basic premise is that change is costly and that attempts to reduce or eliminate change are futile, so why don't work at making change less costly by writing code that is more communicative, simpler and more flexible.

The actual implementation patterns are described in chapters five through nine. Each chapter covers a certain group of patterns: Class, State, Behavior, Methods and Collections. These chapters can be read in any order but the patterns within a chapter do seem to build on each other so it would be best to read each chapter front to back. The authors casual writing style makes this easy to do. The patterns themselves are mostly techniques you already use but might not think of as "patterns". Looking at them this way can make it easier to use them consistently and confidently.

Chapter ten is a look at the additional considerations when using implementation patterns in the context of building frameworks. The author uses his work on the JUnit framework as example. I have to admit, that since I don't write frameworks, I didn't spend too much time in this chapter. If you do build or maintain frameworks then this chapter looks like it will be very helpful.

Overall I found Implementation Patterns interesting and enjoyable to read. Reading it, however, is only the first step in getting the real value from it. I am now keeping it by my desk and referring to it as I work. It's relatively easy to understand these different patterns and even to describe them to others, but to get the most bang for the buck you need to put them to use.

So, in case you haven't figured this out by now, my recommendation is that you buy this book, read this book, use this book, become a better programmer and enjoy your work.

The treatment in this book is rather basic. I had expected that Kent would build up from the basic premises but it seems to stop right there.Definitely for the novice.

First off, this is a very thin tome. Which would make you expect a brisk pace, but instead, it's strangely just laconic. A lot of it is so elementary, it is kind of maddening. At one point, Kent tells us that if we need to fetch the time for a number of local variables, we ought use a local variable to 'freeze time.' The biggest problem here, however, is that when the book does turn to a topic that is worthy of some attention, the same paucity produces a feeling of futility: some of idioms, like collecting parameter, for instance, come up. No discussion of how it is a gateway to Visitor, nothing really interesting in fact, just a short little paragraph. Another section on parallel hierarchies ends with the author saying that he figured out how to solve his rather stilted example by introducing a CashFlow object. But he goes on without explaining it. Now, consider the fact that I believe books should ONLY take up topics like that one. This book is greatly confused about who it is for. The reality is this is probably best suited as a tome for people who have been doing basic programming but have not become really mature programmers. The problem is that it only does this in a way that I don't think will help those who have not crossed the bridge to do so. Ironically, I think the main use for this book will be to make people who are doing a lot of these things feel better about it.

This book is a wonderful, concise book on writing code that others can understand. I love Beck's premise in his intro: "Actually, this book is based on a rather fragile premise: that good code matters. I have seen too much ugly code make too much money..." A pretty amazing blurb, but Beck goes on throughout the book to prove why you should care about good code and how you can do a better job of writing non-ugly code that others can more easily grok out.

The book's chapters run a short gamut of great topics from programming theory to frameworks. One of the more intestesting bits I found was his discussion on symmetry, the idea that methods and classes should be well balanced. Methods such as "Add()" should be balanced by "Remove()", and that ideas in sections of code should be expressed in the same style, i.e.

void process() {
input();
count++;
output();
}

where input() and output() are intentions while count++ is an implementation. Esoteric, but the flow is much cleaner and clearer when you read the snippet below instead.

void process() {
input();
tally();
output();
}

I like the discussion in this book is on good naming styles, something I'm passionate about -- and am still not happy with my own practices in that area. There's also great text on state, behavior, and different ways to look at methods.

This book's an easy read. Beck's writing style is absolutely approachable, and the book's quite short at 155 or so pages.

Beck's book helps me to better consider how to rephrase my code so its intent is clearer and it's more maintainable by myself and others on my teams. Highly recommended.

"Implementation Patterns" is a great book to make better Java developers. The focus is to make us think about writing more readable and maintainable code. Kent Beck accomplishes this by going thru WHY we write things a certain way.

The audience is Java developers who know the basics of the language. If you have more experience, you will understand points on a deeper level. If you are newer to Java, you will form good habits.

There were just too many things I liked about this book, so here's a list:
- clear, concise and short snippets
- simple, bare-bones diagrams
- discussion on caveats and tradeoffs
- over 100 pages of patterns
- over 75 patterns
- about concepts and OO; not a style guide
- focus on values like communication and simplicity
- section on cross cutting principles like minimizing repetition
- short sections (Kent says some chapters long, but 30 patterns in 30 pages has great subdivision)
- how JUnit 4 design decisions follow theses patterns
- Kent even got in a dig about Sun never removing deprecated code
- bibliography with a blurb from Kent on each title
- pattern index on inside back cover in addition to traditional index


The book can be read straight thru or used as a reference. It's short, light and easy enough that it can be read on an airplane. (and in this case, it was.) It's also organized enough to go back and read about the pattern relevant at the time.