Dr. Dobb's Journal January 1998
Put a bunch of thirty-something programmers together and they'll soon start talking about their first machines. Ah, the TRS-80 (or PDP-11, or Apple II, or whatever). Those were the days, eh? You really knew what your programs were doing. You didn't just know what each byte of memory held, you knew what each byte was called.
Frankly, I don't really miss those old machines. I like having megabytes to play with and a processor that's fast enough to support "fluff" like a context-sensitive editor for a templated, object-oriented programming language. One thing I do miss, though, is the size of the books. Kernighan and Ritchie's The C Programming Language was 228 pages long and weighed only 12 ounces. Sure, the type was a bit small and layout a bit dense, but it was eminently readable, and opened up a whole new world of programming back when UNIX was still a new fangled operating system.
Gary Cornell's Visual Basic 5 From the Ground Up is to K&R what Windows NT 4.0 is to UNIX System 7 -- bigger but not as cleanly done. The book is 778 pages long, and covers the whole of Visual Basic, from the programming environment to the properties of common controls to ActiveX. The writing is clear, and there are lots of diagrams and tables and plenty of example code. But as a newcomer to Visual Basic, I found that Cornell's breadth-first presentation sometimes left me floundering. Instead of a list of the most commonly altered properties of a text box, for example, I would rather have had a look under the hood at how VB5 connects the code I write to the display on my screen. One thing that all my favorite books on programming languages do is give the reader a clear mental model of what the language is doing. Without such a model, I feel that I am memorizing a cookbook, rather than making myself comfortable in someone else's workshop.
Having said that, Cornell's book is easily the best of the three or four Visual Basic books I've tackled. It is easy to read, well organized, and has a useful index. And I'm sure that much of its size is simply due to the size of the system it describes: The complete Visual Basic environment, including development tools, controls, ActiveX support, and so on, is many times larger than the circa-1980 C compiler I remember fondly. VB5 gives better error messages, too...
In contrast, Martin Fowler's UML Distilled proves that you can still say a lot of useful things about computing in a small book -- at 179 pages, it's even smaller than K&R. "UML" stands for "Unified Modeling Language," a second-generation object-oriented design notation developed by Booch, Jacobson, and Rumbaugh that unifies and extends the authors' earlier notations. With the backing of the Object Management Group and several major software developers, UML looks set to become a standard notation for describing class hierarchies, instance relationships, use cases, and a whole lot more. (For more information on UML, see http://www.rational .com/uml/index.html.)
This book is one seasoned developer's guided tour of UML. After giving a bit of background on UML's genesis, Fowler outlines the sort of development process that UML was designed to support. Unlike most such discussions, this one is both readable and level headed; Fowler clearly has a lot of experience with real-world projects, and considers "doability" much more important than ideology. For example, he devotes a few pages to "refactoring" code -- reorganizing class hierarchies after the fact in the light of new understanding about the problem domain. Every programmer I know does this, but you'll have to look very hard to find it mentioned in any of the classic software engineering texts.
Chapters 3-10 are the meat of UML Distilled. In each chapter, Fowler describes a single aspect of UML, such as its activity diagrams or case notation, and shows how it should be used and how it fits into the overall development process. The examples are easy to follow, the diagrams are clear, and the author's enjoyment of his work comes through again and again. While I expect that most professional programmers will continue to work with ad hoc sketches (What's the difference between a programmer and an old dog? You can teach an old dog new tricks!), I can think of no better basis for an undergraduate course on software engineering than pairing Fowler with Steve McConnell's Rapid Development (Microsoft Press, 1996).
The CRC Card Book, by David Bellin and Susan Suchman Simone, is longer than UML Distilled (290 pages), but could have been much shorter. CRC cards are a brainstorming technique: The acronym stands for "class, responsibility, collaborators," which are the three bits of information each card holds. During a design session, individuals role-play different classes; each class is only allowed to do what is written on its card (typically a 3×5 index card), and may talk only to those collaborators whose names have been written down on the card. It is a simple but effective way to uncover gaps or redundancies in object designs.
It is also simple to explain. To make a whole book, Bellin and Simone have unfortunately padded that explanation with a hurried introduction to object-oriented programming, overly lengthy case studies, and a chapter each on going from CRC cards to actual classes in Smalltalk and C++/Java. I, for one, would have grasped the book's point without soap-opera prose like:
Joe took a stab at the problem. "Even though I am not a computer person," he interjected tentatively, "I am beginning to catch on to the way you think, DeWayne."
The final title in this month's review is GUI Design Essentials. I finally left my old UNIX command line behind about a year ago, and have been wrestling with Microsoft Windows ever since. Part of that struggle has been learning how to create graphical interfaces that don't suck. It's not that I think I'll ever become a digital Picasso, I just don't want my working partner (who is a user-interface designer) to say "Eeeww" each time one of my little dialog boxes comes up.
I think GUI Design Essentials, by Susan Weinschenk, Pamela Jamar, and Sarah C. Yeo, is as close as I'll ever get to finding the book I've been looking for. Many GUI books are primarily about design, and are full of profound but essentially useless prescriptions such as "Use space creatively" or "Your design should be balanced, but hey, asymmetry can be cool, too." This book, in contrast, is primarily about GUI construction. The first part is about the mechanics of designing an interface: requirements gathering, prototyping, usability testing, and so on. The remainder is made up of checklists: Avoid horizontal scrolling; place pop-up windows in the center of the action; limit checkboxes to ten. The final chapter lists some best-practice guidelines with section headings like "Who to Involve" and "What to Customize."
My working partner is less impressed by this book than I am, primarily because she knows enough about the field to be able to think of exceptions to every one of the authors' rules. However, I think it's a good starting point for the aesthetically challenged. If nothing else, following these guidelines will ensure that any mistakes you make are uncommon ones.
DDJ