Spring: A Developer's Lesson

Bruce Tate and I, on the heels of Better, Faster, Lighter Java, set out to introduce people to Spring. Committed as we both were to the ideas we were espousing (simplicity, ease of configuration, choosing tools that get out of your way), and admirers of what Rod and company had done with Spring, we wanted to write a book that would let people get right at the things that make Spring sing. O'Reilly suggested the book would fit well into the Developer's Notebook series, a code-heavy, to-the-point format that would highlight code and not prose. We agreed, and were off.

The end result of our work, published just two weeks ago, has flaws. Instead of waiting for the inevitable trickle of mediocre to poor reviews to poison the book on Amazon, though, I want to acknowledge those flaws now. Oh, its a good book which does what we intended it to do: introduce developers new to Spring to the variety of ways it can make their lives easier. Its flaws are not in intent, or even content. The flaws are in the execution.

There are typos, for sure, but every book has typos. There are mislabeled figures, and missing angle brackets at the end of XML snippets, and a variety of errors that creep into any book. Those are what errata pages and reprints are for, and you'll find both attached to this book. The bigger problem is with omissions: as the chapters progress, important pieces of information about how to make the code you see in the book run are missing. A taglib here, an interface there, a new dependency in the /lib directory over here, and it all adds up. People who try to follow the code in the book and make it run, quickly run afoul of these frustrating omissions and start getting (rightfully) upset.

Perhaps we were relying too heavily on people's willingness to download the code samples and dependencies. That, I believe, was the heart of my mistake, anyway. And the kernel of a valuable lesson: when you set out to make a book, *make a book*. Not a book, plus a website, and a blog and an errata page. If you want to write a book for print, make sure the book contains everything that it might need, soup to nuts, within its covers. The downloadable code all works; I urge readers of the book to grab copies and refer to them as you read the book. We broke them up by exercise in the book so it is pretty easy to see what has changed.

But you shouldn't have to, and for that, I apologize. We're issuing a reprint of the book now that fills in those holes. In the meantime, you can find the missing pieces on the errata page or follow along here as I enumerate them over a series of posts, starting with the one right after this.