Joshua Bloch wrote Effective Java and Brian Goetz was the lead author of Java Concurrency in Practice (Joshua Bloch was one of several co-authors on this book as well). How do we know these books have been successful? Perhaps the most obvious sign of success (especially to publishers!) is the number of copies sold. This is often related to the number of printings and/or editions of the book. Bookseller web sites such as Amazon.com also list where these books rank in terms of overall book popularity and in narrower categories. For me as a developer and user of these books, however, there are even more important indicators of how "good" a technical book is. One sign of a good technical book are consistently high ratings of the book across reviewers and across sites selling the book. An even better sign, for me, of a good technical book is how many copies I see of it sitting on my colleagues' shelves. I definitely have seen many copies of both Effective Java and Java Concurrency in Practice on the shelves of many of my colleagues and both of these books get consistently high ratings on bookseller web sites.
With the prevalence today of blog entries, online articles, and even freely available online books, it is becoming more important than ever for a software development book to provide some value above and beyond what these freely available resources can provide. If a book doesn't provide much beyond what is available freely on the web, it likely won't sell well and almost certainly won't see many printings or editions. The online resources are especially effective in releasing information quickly, so books have a built-in disadvantage in terms of timeliness of delivery.
I have no idea which specific books will be discussed in this Birds of a Feather session or what traits of good technical books will be discussed. However, I have my own opinions of which books are the "classics among the classics" in modern software development and I similarly have some theories and observations about common traits of these books.
My list of the "classic technical books" (not necessarily Java-specific or even Java-related) would likely be slightly different on any given day I put it together, but as of right now of this day, here is my list, in no particular order.
Expert One-on-One J2EE Design and Development
While this book may be best known for exposing many of the inadequacies of the hyped EJB 1.x and 2.x technologies, for the first public exposure to what would become the Spring framework, and for (along with the follow-up book J2EE Without EJB) leading to significant improvements in the EJB3 (and Java EE 5) specifications, it remains a deep treatise into practical Java EE architectural and design principles. Even now, years later and several specifications later, there are vast amounts of applicable and useful information packed into this book. When I first read this book, I was relieved to see that I was not the only one who had misgivings about EJBs. After reading so many things in this book that articulated my own thoughts and opinions better than I ever could have, I was very open to the author's thoughts on things with which I did not have as much experience. I truly firmed up my opinions and realized many other lessons from reading this book. It is, I think, a must-read for all Java EE developers even today.
Effective Java
This is another "must-read" book for Java developers. While a few things are now not as applicable as they used to be (such as Item 21 on enums), most of the book is still as applicable today as it was when it first came out. In fact, even some of the most basic items (such as always overriding
toString(), still get neglected more often than they should and I think we all benefit from reading and re-reading this book. I like to flip this book open randomly to an item or two now and then just to refresh my knowledge.Effective C++ and More Effective C++
With the new edition of Effective C++ now covering 55 items rather than the original 50 covered items, these two books now cover 90 items for effective C++ design and coding. For the first time in my career, I'm actually not using C++ currently, but these books were tremendous aids for my many years of C++ development.
Patterns of Enterprise Application Architecture
The PofEAA book contains two main parts and I spend the majority of my time in the first (and shorter) part (called Part I: The Narratives). This section of roughly 100 pages provides an excellent overview of architecture considerations in enterprise applications. The remainder of the book (Part II: The Patterns) focuses on specific enterprise patterns and I do use it for a reference on certain patterns at times, but I find the overview and conceptual coverage to be widely useful in my daily development efforts.
Design Patterns: Elements of Reusable Object-Oriented Software
Although there are now numerous books on design patterns (including books specifically on Java and design patterns such as Core J2EE Patterns, the Design Patterns Java Companion, and Holub on Patterns), the Gang of Four Design Patterns book is still THE design pattern book. I cannot think of a single book that is more widely owned by my colleagues than this one. Nearly 100 percent of the C++ and Java developers I know own this book.
When I first read the Design Patterns book, I thought it was terrible. Sadly, I did not revisit the book again for several years. However, when I did read it again, I was amazed at how insightful this book had become. This book is worth owning or borrowing from the library or borrowing from one of the many colleagues who have a copy for just the first chapter alone. In fact, as I described with the Fowler PofEAA book above, I only refer to the cataloged patterns directly now and then, but I often use the first chapter to illustrate the importance of concepts such as favoring interface inheritance over implementation inheritance and favoring composition over implementation inheritance. The aforementioned Holub on Patterns book has similar (albeit more strongly worded) focus in its first part as well.
The Practice of Programming
Although somewhat dated (publication was in 1999), this book still speaks to many of the frustrations and hard-earned lessons experienced developers have encountered. This book can help experienced developers realize how to avoid the problems again and help new developers hopefully reduce these types of negative experiences. One of the undersold advantages of this book is its relatively short length. There is a lot of experience packaged into a little book.
Code Complete
This book covers a wide gamut of software development as illustrated by its really detailed contents listing.
201 Principles of Software Development
One of the key strengths of this book is its creativity and usefulness in filling a niche. This book covers 201 proven software development principles in very short text sections (usually a paragraph or two) that fit completely on one of the book's small pages. Each topic also includes references to authoritative resources focusing in significantly greater detail on that topic. The association of topics with these authoritative resources is a worthwhile collection in its own right, but the concise textual summarizations of each topic are highly useful. The topics cover everything from general development and design principles to software management principles.
This book and its author reiterated something that I have always believed -- that the software development industry moves in cyclic patterns, repeating periodically the same basic trends of earlier years with new names and technologies. I was fortunate to attend a Denver Java Users Group meeting (October 2006) where the author, Alan M. Davis, spoke. It was an excellent presentation where he explicitly tied some of the "newest" and "trendiest" ideas in software development to suspiciously similar concepts and ideas that were popular several years or even decades ago.
The Mythical Man-Month
One of the most quoted books in the software development industry (in its literature and among its artisans), this book really focuses on how management and mismanagement of software projects contributes to the success or failure of a software project as much as the technical capabilities of its developers. Although this book is somewhat dated by technology standards, it is still true and still on the mark. The programming languages and concepts have changed, but the general manager-developer impedance mismatch still exists.
So What Makes These Books Classics?
The books I listed above share many characteristics that seem typical of software development books that become classics. Here is my list of current thoughts on what makes these and select other books rise above the rest.
Authoritative Nature
One reason I might purchase a book on a subject that is covered already by online resources is because of credential of the author or the authoritative nature of the book and/or author. For example, an attractive feature of the book Pro EJB3: Java Persistence API was that its lead author, Mike Keith, was a co-lead of the EJB3 (including JPA) JSR-220 specification. It turns out that I really like this book and I believe that much of its value comes from the expertise of the two authors. Other examples of this include Ruby on Rails creator David Heinemeier Hansson being a co-author of the tremendously successful Agile Web Development with Ruby on Rails book (along with Dave Thomas and others).
All of the books I have listed above as "classics" are associated with authors who are arguably authoritative. Even when their formal credentials may have lacked when they wrote the book, the writing speaks for itself and in many ways establishes their informal authority.
Readability and Detail Abstraction
While many of us want our technological books to be authoritative as described above, we don't want the language or concepts to be at a specification or too technical level, especially in introductory books and chapters. After all, the reason most of us do buy books instead of accessing online resources such as standards specifications and early blog entries is that we want a uniform, consistent, abstracted treatment of the technology or concept. We also want it presented in a perhaps more introductory way for new technologies or we want new insights, lessons learned, and best practices for more mature technologies.
An example of this is the book Learning Perl. I'm not a fan of Perl, but I think the first chapter of this book is one of the most useful chapters written in any technology book. Because I only use Perl when I absolutely must, I don't use it much and don't know it well. However, I can usually get 50% to 75% of what I need to do each time I return to Perl from this first chapter alone. The first chapter gently leads the reader through some basic concepts while teaching some of the most frequently used features and syntax along the way.
Most of the "classic" books I highlighted above bring clarity or abstraction to more difficult design and development concepts.
The Subject Matters
The subject matter of the book does influence the potential of a book to be a classic. No matter how well written the book is or how qualified or authoritative the author is, a book can only become a classic if it is able to influence numerous developers. With this in mind, it is no surprise that the books in my list of "classics" are associated with long-term (and widely used) programming languages like C++ and Java or are so general in nature that they can span different programming languages. No matter how "good" (a very subjective measure) the programming language, if few people use it, it is very difficult for a book focused on that language to ever be popular enough to become a classic.
Because programming languages do come and go, the books that are largely language-independent have the best chance to be true software development classics. Books with a programming language focus can still be classics in that language's community, but really need a language with a long life to be considered classics.
Beyond 'Hello World'
With the ready and timely availability of information on new languages and development concepts, it is increasingly difficult for a mediocre book to add much value even for new languages and concepts. In general, it is difficult for a general technical book to do well solely because it's first to market. There are some examples of books whose quality and introductory content have made them hugely successful (such as the Core Java series, the Java in a Nutshell series, and the Java Cookbook), but it is more difficult for books like these to become classics because there are so many introductory and basic books in these popular areas. This is where books like Java Concurrency in Practice can shine. Books such as these are more specialized and in-depth.
As an author of several online articles and blog entries, I feel somewhat qualified to point out that many online resources (including mine) tend to focus on basics and introductory material. There is nothing wrong with this and resources like this are needed, but this also leads to an opening for more focused and detailed books to thrive. It is far more difficult to write a good focused and detailed book or article than it is to write an introductory book or article, but the value from the effort for the reader is huge.
IN SUMMARY
I want to finish this lengthy blog entry with one final example differentiating a good book from a classic book. I really like the Programming Flex 2 book, but I would not call it a classic (yet). While it is a great introduction to Flex, its ability to ever be considered a classic depends largely on the future of Flex. Being language-specific is an automatic disadvantage in terms of a book being considered a classic ten years from now and almost certainly a Flex 2 book cannot be a classic a decade from now. That being said, variations of this book for future versions of Flex could be collectively considered classic if Flex gains in developer popularity.
I like this example because it shows that a great book will not necessarily become a classic technical book. Another perspective on that idea is that a "good technical book" does not have to be a "classic" and can still be a simply "good technical book." There are many more "good technical books" than "classic technical books." The example also illustrates how the most likely books to be considered "classics" more than ten years from now are those that are not tied to a specific programming language. Other books that fit the "good technical book" (but perhaps not yet classic) category for me include Agile Web Development with Ruby on Rails, Spring in Action, JMX in Action, Effective XML, Java Threads, and Pro EJB3: Java Persistence API.
This all makes me wonder about my own list of "classics" shown above. Will I still have books like Effective C++, Effective Java, and J2EE Design and Development on that list in ten years? I almost certainly will still have 201 Principles of Software Development and the Mythical Man-Month on that list in ten years because the covered principles in those books aren't likely to change much even in ten years. However, I'm not as certain that the language-specific books on my list of classics will be as influential then.
By the way, another potentially interesting presentation that caught my attention is "JavaScript™ Programming Language: The Language Everybody Loves to Hate" (TS-4986). I loathe JavaScript, but it is a necessary evil for much of the web development community. One of the things I have most enjoyed about using OpenLaszlo and Flex lately is leaving browser-dependent JavaScript behind (Flex uses ActionScript and OpenLaszlo uses its own browser-independent JavaScript subset).
No comments:
Post a Comment