Dr. Dobb's Journal March 1997
The way programs are written today has a lot in common with the way bridges were built before Newton and Leibniz invented calculus. Like Roman engineers and medieval masons, we rely on past experience and rules of thumb rather than science, and, like them, we have managed to build some impressive, long-lived structures without really knowing why or how they manage to stand up.
Rapid Development, by Steve McConnell, reads like something a 30-year veteran with a half-dozen bridges or cathedrals behind him might have written for the benefit of his junior colleagues. McConnell's previous book, Code Complete, was a handbook of do's-and-don'ts for working programmers. It covered everything from how to avoid common mistakes in C to how to set up a testing framework, organize multiplatform builds, and coordinate the members of a team.
Rapid Development is similar in style and breadth, but is aimed at lead programmers and others who find themselves running the technical side of projects. The five chapters in the first section discuss what it takes to develop robust code quickly, what mistakes are often made in the name of rapid development, and how to identify and analyze potential risks. The second section looks at particular practices in detail, including schedule estimation, managing programming teams, controlling feature creep, and recovering from disaster. The mere presence of this last topic is a sign of how this book differs from most software engineering texts: McConnell has clearly spent a lot of time in "Dilbertspace" and knows that getting out of holes is often as important as digging them.
The third and final section of the book lists 25 best practices and gives an even-handed assessment of what each can do and when each is applicable. The practices described include instituting a change board to control feature creep, using a daily "build and smoke" test to track progress, outsourcing development, and using staged delivery to ensure shipping dates are met. Some of this material is now available in McConnell's column in IEEE Software magazine.
Unlike most "how to do it better" books on computing, this book isn't trying to sell a particular practice or style. The significant fads of the last 25 years are mentioned, but each one is examined critically and its benefits quantified so far as is possible.
Good programming skills are to computer science what good laboratory technique is to biology, except most computer-science departments don't explicitly teach their undergraduates what they need to know. A one-year course using Code Complete and Rapid Development as texts would go a long way toward fixing this problem; the hard part might be persuading professors to read them as well.
Does Rapid Development deserve to stand with such classics as Kernighan and Plauger's Software Tools or Weinberg's The Psychology of Computer Programming? Not quite. While Rapid Development has a strong central theme -- good development practices -- it is a survey and, as a result, is a bit hard to digest when read straight through. It also never quite addresses a key issue head on: what to do when your boss can't be talked into following good practices. In the scenarios that bracket each of this book's chapters, the programmers who Do It Wrong come to grief, while those who Do It Right come out well. In the real world, programmers can estimate schedules carefully, analyze and prioritize risks, and still wind up being told that they have three weeks, instead of six months, to deliver the finished product. Perhaps McConnell should have included a chapter on when and how to resign.
As good as Rapid Development is, Graphic Java, by David Geary and Alan McClellan, will probably be more widely read, at least this year. Whatever else it may be, Java has been a publishing bonanza: My local computer bookstore has three dozen Java titles on its shelves, and more arrive every week. Most of these books are hastily written descriptions of the syntax of Java and of a few trivial applets. In contrast, Graphic Java is a careful, detailed explanation of an important but flawed part of the standard Java API and of a new package that fixes many of those flaws.
The first half of this book's 600 pages describes the Abstract Windowing Toolkit (AWT), Java's standard windowing environment. The chapters cover the fundamental Applet class; basic graphics operations, such as drawing shapes and displaying text; handling events, such as button clicks, mouse motion, and key presses; creating menus; displaying images; and how layout managers control the appearance of complicated interfaces. While almost every Java book covers the AWT, none that I have read does so as well or provides such good advice on how best to use it.
The second half of the book describes a package called the Graphic Java Toolkit (GJT), which fills some of the holes in the AWT and adds some much-needed functionality. Its chapters cover separators and bar gauges, borders, image and state buttons, tool bars, rubber banding, dialogs, scroll bars, and animated sprites. None of this is rocket science, but that fact can make the authors' job harder, since everyone using Java brings to it different expectations developed in the Macintosh, Windows, or Motif environments. As in the first half, the authors cover "why" and "how" as well as "what," and they provide many examples.
My only complaints about this book are typographical: Bad word breaks appear in the diagrams and there are a handful of typos in the text; I expect these to be fixed in the second edition. Unlike most Java books, this one is good enough to deserve a second edition.
Finally, anyone who is serious about Java as a programming language should take the time to read the Technical Memo MIT/LCS/TM-553 from MIT's Laboratory for Computer Science entitled "Parameterized Types and Java," by Joseph Bank, Barbara Liskov, and Andrew Myers (http://www.pmg.lcs.mit.edu/~andru/pubs.html). Like object-oriented programming, generic programming is an idea from the 1970s that has taken 20 years to enter mainstream computing. As more programmers become familiar with generic programming, as exemplified by C++'s Standard Template Library, the power of this "new" form of abstraction is being more widely realized.
In this paper, Bank, Liskov, and Myers discuss an implementation of templates in Java that is type safe, which permits separate compilation, and which (unlike most implementations of C++ templates) does not lead to code bloat. If Java is to fulfill its promise of being to C++ what Pascal was to Algol-68, some form of genericness will eventually have to be added. So far, the work described in this paper is the best candidate I've seen.
DDJ