The bibles of our industry
The four most important books in your library do not have Java in their titles
In this article, I present a treatise on the subjects that separate the rookies from the pros in Java development and a reference to the books that will help you cross that line. This is not a book review under the guise of an article. This is your ticket to the next step in your career development.
Java is a programming language. It is also a tool, and a tool in the wrong hands is useless, sometimes even dangerous. Knowing only the syntax and semantics of Java does not a programmer make. A programmer must also know and understand intimately the environmental paradigm, which in Java’s case, is object-oriented design. It is not enough to understand what an object is, what an interface is, how objects implement interfaces, ad nauseam. A programmer needs to know the mystic ways in which those rules and relationships can be combined into flexible, reusable, and scalable systems. The books that I discuss here will give you those lessons and enhance your career as a Java developer. Ironically, none of them contain the word Java in their titles.
Note: URLs for all books discussed in this article can be found in Resources.
Design patterns
To paraphrase the book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, and Grady Boocha (Addison-Wesley, 1995), a pattern describes a recurring problem and proposes a reusable solution. Patterns simplify your job by helping you avoid the pitfalls of memory limitations via object sharing — with Flyweight, for example — or create a swapable integration with third-party libraries such as Facade. Design Patterns details those two patterns, plus a score more, and provides code examples and easy-to-understand diagrams. Although the code samples are all in C++, the syntax sufficiently resembles Java; most programmers will thus have no problem grasping the concepts. There is an imitation of this book available that uses Java for the examples — Java Design Patterns: A Tutorial by James William Cooper (Addison-Wesley, 2000) — but you won’t find the same clarity and depth that the Gang of Four (the authors’ established nickname) conveys in Design Patterns.
Once you are familiar with the patterns cataloged in Design Patterns, learn how some of them evolved. In Pattern Hatching: Design Patterns Applied (Software Patterns Series) (Addison-Wesley, 1998), John Vlissides — one-fourth of The Gang — recounts the debates and discussions over some of the more popular patterns and introduces some new patterns that didn’t make the cut in Design Patterns.
Refactoring
To err is human. If that is true, I’ve seen hundreds of programs that are more human than I. Projects go wrong. Mistakes are made. Schedules slip, and quality is sacrificed. Those make up the caveats of our profession. But where do you turn when things reach their worst? Too many of my colleagues belong to the “throw-away-and-start-over” camp: start over from scratch and hope that you’ve learned from your mistakes. That is the most extreme solution, one that is sure to infuriate your boss. But don’t despair because there are alternatives.
Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series) by Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts (Addison-Wesley, 1999) offers developers various options to starting over. Refactoring is the process of improving performance by reorganizing a program’s internal structure without altering external behavior. Refactoring could make a method run faster or provide more accurate results without changing the method’s signature. The changes are invisible to the programs that call the method, so no code requires modification.
The book teaches the reader how to identify problematic code by associating it with a particular smell and relates each to a catalog of procedures for repair. For example, a smell might be Inappropriate Intimacy, which describes two or more classes so tightly integrated that a change to one requires a change to another. One of the handful of possible solutions that the book suggests is Move Method, which constitutes the relocation of the smelly method into a more appropriate class.
Antipatterns
Software design isn’t the only area prone to missteps and oversights. Management is equally susceptible to the pitfalls of the chaotic development process and surreal schedules. Most Internet shops have an alarming rate of employee turnover in their development departments. As programmers come and go, the hierarchy of responsibility becomes as convoluted as the source code structure. That is where the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J. Brown, Raphael C. Malveau, William H. Brown, Hays W. McCormick III, and Thomas J. Mowbray (John Wiley & Sons, 1998) fits into your overall career objectives. It catalogs common errors in planning and mismanagement and postulates ways to dig yourself out of the abyss.
Does your project suffer from the Design by Committee antipattern, meaning that too many chefs are spoiling the soup? Or perhaps your code base has fallen into the Vendor Lock-In antipattern, leaving you dangerously dependent on a third-party product. AntiPatterns classifies a dozen of those issues and about two dozen more mini antipatterns, and guides you in avoiding them and in breaking free from the traps you happen to fall into.
Extreme programming
Extreme programming (XP) is a fresh and somewhat controversial new development process spearheaded by Kent Beck. XP strives to deliver good software on time without the bureaucracy and paper trails of traditional development. In the hectic environment of Internet startups, everybody focuses on time-to-market. In the real world, projects that run over budget and past their deadlines get cancelled, causing some companies to eventually fold. The reams of documentation and diagrams produced at the beginning of the project rarely reflect the final product. Thus, development teams need to be adaptive and responsive to frequent changes in the project’s requirements. That is where XP shines.
“Communication, simplicity, feedback, and courage” is the mantra of the XP devotee. Achieve communication by, for example, programming in pairs. One person codes while the partner performs a realtime peer review.
Simplicity argues for building only what you need when you need it. Don’t waste time engineering extravagant solutions for problems that might arise in the future.
Feedback relates to the “release early, release often” rule of which so many open source fanatics are fond. By putting the product in front of the customer’s face early in development, you are more likely to avoid drastic change requests later in the cycle.
Finally, courage urges the XP disciple to take chances and learn from the results. On rare occasions, you just might have to resort to the “throw-away-and-start-over” technique. That mantra along with how XP can help you are described in Extreme Programming Explained: Embrace Change by Kent Beck (Addison-Wesley, 1999).
Conclusion
I was recently awarded the opportunity to start a company from scratch. My development teams live and breathe by the teachings of those books, and the results have been phenomenal. We’ve built extremely robust and scalable systems, on schedule, with no overtime. Those books have changed my career for the better, and I believe they can change yours as well.
