Monday, October 26, 2009

Maintaining a Software Development Library (Books)

For as long as I can remember, I have always loved books. When I was growing up and my parents would offer to buy my brothers and me something at the store, I'd almost always select some fictional book while my brothers would select toys. As an adult, I don't read as much fiction as I'd like, but I do buy and read (at least portions) of a lot of technical books. I've got technical books strewn around the house in several different book cases in several different rooms. My wife asks me to take more of them to work, but I have my two long book shelves at work filled as well. In this blog post, I look at why I value these books (versus the information freely available on the web), how I get many of them for really low prices, and how I finally determine when a book has gone beyond usefulness to uselessness and often even to being a hindrance.

Why Books?

With the prevalence of blogs and online articles, why do we even need technical books? I have found that blogs and articles can be superior to books in terms of cutting-edge knowledge and in terms of strange corner cases. However, books are typically better at providing "big picture" introduction to a topic and at providing in-depth thorough coverage of a topic. Books can also be taken just about anywhere, though e-books are becoming more portable with devices such as the Amazon Kindle. I still prefer the ability to write notes in my book and I find that my memory of a certain concept or description seems to be better with physical associations I make mentally. Books often provide more consistent and thorough coverage of a topic than can be covered in a collection of blog posts and articles, even when written by the same individual or team.

Acquiring the Technical Book

I have purchased some real stinkers when I have not adequately researched what I was purchasing. Fortunately, I have gotten better at picking better technical books. There are several factors that aid in this process. Reviews on sites like can be insightful, especially when reviewers express why they like or dislike a particular book. There are also many bloggers who post reviews of technical books. Furthermore, many users groups also provide book reviews. Asking fellow developers and colleagues about the books they own and/or have read can also be enlightening. It is best to consider a wide set of reviews rather than a single review when trying to determine whether to purchase a particular book.

I have sometimes made a decision to purchase a book after borrowing it from a colleague or from the library. This was the case with the Second Edition of Effective Java. I was "on the fence" about purchasing the Second Edition (until it fell in price on the Amazon Marketplace at least) until I borrowed a colleague's Second Edition and realized how much was added in that edition. I have also found several highly useful books and some not-so-useful books after borrowing them from the library and evaluating them. In a few cases, I have gotten the tip or piece of knowledge I needed from a particular book during the period I had it borrowed from the library and did not need to purchase it after borrowing it.

Many publishers offer sample chapters that allow one to preview a portion of a technical book and this can provide insight to the author's writing style and level of detail. Entire older editions of some books are available online. For example, Bruce Eckel makes old editions of some of his books available online. O'Reilly has its Open Books Project with online editions of books that can be reviewed (and sometimes this is the only way to easily access out of print books). If you like what you read there, you can purchase the latest edition to get up-to-date information.

Speaking of older editions, there can be times when acquiring an older edition of a particular book is satisfactory. An older edition can be much less expensive than the latest edition. Traditional and online bookstores will deeply discount the older editions before the new editions come out. Depending on how important the information in the new edition is, considering an older edition can be a useful approach.

When I purchase a technical book, I often first consider Amazon Marketplace. The Amazon Marketplace has the advantage of being hosted directly on and allowing the purchase to be made via Amazon using one's Amazon account. This implies no need for a special account and means that Amazon handles the financial transaction. I am more comfortable trusting my credit card information with a single vendor (Amazon) than with each individual third-party vendor that sells on Amazon Marketplace. My experience is that the new or used books purchased through Amazon Marketplace often arrive quickly and in outstanding shape.

There are a couple things to be aware of when using Amazon Marketplace. For one, shipping and handling is added to the price and typically purchasing $25 worth of merchandise does not mean free shipping when purchasing through the Marketplace. There are times when the fulfillment is through Amazon on a Marketplace purchase and in some of those cases the purchase can use the free shipping with $25 purchase option or Amazon's other prime shipping deals. There are times, especially for newer and more popular technical books, when it costs almost as much or even more to purchase the Marketplace book and pay the shipping (often $3.99 per book) as it costs to buy the book new directly from Amazon with free shipping.

A second consideration with purchasing books on Amazon Marketplace is that the third-party vendor typically arranges the actual administration of the order fulfillment. This can mean a delay in delivery, though it varies widely from very quick vendors to very slow vendors. If you need the book in the next several days, you might want to consider another option.

Using the Technical Book

Although I love books in general and technical books in particular, I rarely read technical books cover to cover. I have only read portions of most of my technical books. In some cases, I have read the entire book several times, but never cover-to-cover. I have read a few technical books cover-to-cover, but that is the exception rather than the norm.

I like to read portions of many of these books during small amounts of available free time. This can include waiting for a car to be serviced, waiting at a doctor's office, waiting for a train on railroad tracks, etc. I almost always have a book with me in the car for such situations. I also read portions of books directly related to whatever I'm working on at the time.

A technical book is often used as a reference and, in such cases, a good index is highly valuable. I have found that a really good index can turn a mediocre book into a trusted resource. Even the best indexes often lack every term I find myself frequently looking up in the book. Because of this, I have gotten in the habit of adding my own index entries in my most-used books for terms and pages that I expect I may want to look up again in the future.

Besides writing in my own index entries, I also often write notes in my books referencing other sections of the book that are related. I like to record any substantive changes on relevant pages in the book to help address obsolescence that is unavoidable with technical books. For example, the Spring Framework Reference is almost always going to be more current than a printed book can ever hope to be. Therefore, my favorite Spring book has many notes in it adding new or changed features in the Spring Framework that I have found out about via blogs, articles, or reading the Spring reference.

Saying Goodbye

Because I enjoy books so much, it can be difficult to part with one, even when it has lost its usefulness. For one thing, there is always the possibility that I might need it again. It can be difficult to admit that I probably won't. Another hindrance to getting rid of a particular book occurs when it is outdated, but I hesitate to invest in a newer edition or improved version. There are also logistical issues such as how to determine when a book has lost its usefulness and deciding on the best way to get rid of it (paper recycling, book use recycling, trash, etc.).

When a book gets so old that it actually contains information that is no longer accurate, it can be risky to use. This is because it can teach incorrect principles that have to be unlearned and can waste a lot of time trying to figure out why something doesn't work as described in the book. In a worst-case scenario, one might even be dissuaded from using a particular technology because of frustrations that are a direct result of using an obsolete and/or incorrect book.

Some books are easier to get rid of because the covered technologies are obviously obsolete. For example, I shouldn't have much trouble getting rid of my book on J# because it is extremely unlikely at this point that I'll ever need that book. Even better examples are books on specific versions of products or implementations that are no longer available or are no longer regularly used.

With some still-popular languages and frameworks it can be more difficult to determine when a book on the subject has passed its useful life. For example, it is my opinion (assuming one is developing in JDK 1.4, J2SE 5, or Java SE 6) that any book on Java that was written before JDK 1.1 is not worth reading or using. Although a book on JDK 1.2 or JDK 1.3 might be a little better, I really don't think most Java books focused on a version of Java prior to JDK 1.4.2 are worth keeping (or at least regularly referencing). JDK 1.4 was a "game changer" in the world of Java development and it is my opinion that any Java book with real usefulness must address at least that version. Similarly, any Flex book covering Flex 2 or Flex 3 might be fine, but any book addressing Flex before Flex 2 (Flex 1.0 or Flex 1.5) is generally not worth keeping or using.

I typically am too much of a cheapskate to purchase a newer edition of the same book unless the new edition offers enough to justify its purchase. An example of when this has been the case is Effective Java. What makes this example interesting is that even after purchasing the Second Edition, I have retained my First Edition copy. The reason for this is that the First Edition is still largely valid and I like to have it around when I have loaned my Second Edition to someone else or have left it somewhere other than my work desk. The point of this is that even purchasing a newer edition of a particular book may not necessarily mean it is time to get rid of the older edition.

When the time comes to part with a technical book, there are several options. If the book is still relevant (not usually the case for me because I wait until the book is completely useless to anyone to part with it), it can be sold online (such as through the previously mentioned Amazon Marketplace, eBay, or other used book selling venue). A book with some remaining relevance might also be donated to a library, a school, or to fellow developers who are working with the language or technology and don't have a better book (especially if they are using an older version to which the book is more applicable). If a book has become so obsolete that it has no value to anyone, the best remaining option is to have its materials recycled.

There are several good blog posts on getting rid of technical books. These include Don Demsak's Recycling Technical Books, Book Recycling, and How Can I Reuse or Recycle Old Books? (see feedback comments as well), and How Book Recycling Can Help the Environment.

Ideas for Good Technical Books

Looking for ideas for some good technical books to add to your personal library? Here are some lists of others' favorite technical books:
StackOverflow: 'Must Have' Books on Your Bookshelf (2009)
What Is The Single Most Influential Book Every Programmer Should Read? (2008)
Top 100 Best Software Engineering Books, Ever (2008)
The Best Books Every Programmer Should Read (2006)
Coding Horror: Recommended Reading for Developers (2004)
Elliotte Rusty Harold's Ten Must-Have Technical Books (2003)


A technical book can be a valuable resource in improving one's skills. However, most of us want to be careful without our money and (perhaps even more careful) with our time. We want to spend our money and time as efficiently as possible. In this blog post, I have recorded some of the things I have learned to improve the efficiency of money and time I invest in acquiring, using, and finally retiring of technical books.

No comments: