This book makes a lot of things (like error handling) clear. However,
it may seem not deep enough. I give it 5 stars because it did not disappoint me at all.

'Prefactoring' is a book tailored towards higher level project leaders and developers who want a text that reminds/teaches them how to write better code the first time through. Hitting on basic concepts such as how to plan well, testing efficiently, and not wasting time down the road, I feel that this is a helpful book that will make managers and code developers better. There are a lot of negative reviews for this book because of it's nature and the fact that many people say the content is empty but I will have to disagree. While not a revolutionary book, I feel that any text which reminds people of basic concepts and makes them a better developer and team leader is a positive influence. If you are in such a role, take a peek at this text.

****

This book contains much that is obvious and not necessarily profound, but does so in a manner that brings a sense of perspective and levity to an a field that suffers simultaeously from too much thinking and no enough thinking. It also contains enough shreds of a real-world scenario to encourage those who have not travelled this path much to start thinking in the right direction. I've pretty much made it required reading for all my developers. No matter how brilliant, they also need a good dose of common sense! Thanks Ken for a book well written.

Prefactoring is an exposition of principles for software design, laid out in the context of the development of a fictional application. I've never been into that particular style of writing about software design; in fact, it was the only thing I didn't like about Martin Fowler's Refactoring, which is the inspiration for both Prefactoring's own fictional case study and its name as well.

When you've got one programming book named after another one, one reasonable idea is to compare the two. Prefactoring's premise is that, instead of fixing your design afterwards -- an extremely terse summary of Refactoring -- you apply what you've learned from that in the past to build it with the right design principles from the get-go. That sounds like good common sense, and it is. Unfortunately, it really only makes sense in the context of a misunderstanding of Refactoring. Refactoring and debugging are different things. It's very common in software for people to use buzzwords and catchphrases as an alternative to thinking, and consequently, in certain organizations, you'll hear "refactoring" used as a synonym for "debugging."

In fact, refactoring is supposed to happen during debugging -- but it's also supposed to happen during the course of development, and in fact this is the preferred time to do it. Refactoring comes from agile development, specifically Extreme Programming, where the basic cycle is to write unit tests, write the simplest code that can possibly satisfy those tests, refactor that code, and then begin again with new unit tests. Refactoring can mean improving things during debugging, but much more importantly, what it really means is streamlining existing code as you refine it. To say that the best thing to learn from refactoring is to get your code right first time is to use the vocabulary of agile development to advocate waterfall development, and this, in fact, is what Prefactoring often seems to do.

Worse still, many of the code examples are in Java, and they don't use Josh Bloch's guidelines from Effective Java or Java Puzzlers. This might be a quibble, but I'd certainly hire or fire based on this quibble, as I think it's very important (and therefore not a quibble at all). Pretty much everything I've done for months has been in Ruby on Rails, so I'm frequently reminded that Java is not popular in every sector of the tech industry -- however, if you are going to write Java, I personally feel that writing Java without observing Bloch's guidelines is careless at best, and borders on outright negligence.

On the other hand, I seem to be kind of eviscerating this book here, and that's not quite fair. I disagree with some of the design principles laid out in this book, but most of them are pretty strong in the common sense department. Also, software development is one of those things where you can be better off after reading a book even if you disagree with it. For instance, just in criticizing this book's attitude towards refactoring, I've had to question my own understanding of it. If you read this book with the right frame of mind, you'll challenge your own ideas and come to new conclusions, and probably become a better developer in the process.

The title "Prefactoring" is of course chosen to get you to buy the book, because it sounds like the popular "refactoring". The first few pages make it clear that "prefactoring" = "good design" + "learning from your experience". The design principles the author chooses are abstraction, separation of concerns, and readability. A nice choice if you want to keep things simple. The rest of the book, though, is a worked example where the author takes you through talking to the customer and shows you all his design decisions based on the principles and the context of his example. The problem is that your context is not his context. (Author himself says right at the beginning that "context is everything" i.e. how you apply a design principle depends on the specific context of your project and code.) So skip this book, read existing books on good design and coding, and apply them in your own "worked example" -- your work. And get weekly professional code review by someone you respect.