Dr. Dobb's Journal November 1997
Iam not too demanding as a reader. I just want authors to explain things clearly and concisely, without trying too hard to be funny or profound. A few tidy diagrams to help me get through the difficult bits are always appreciated, of course, as is a title that accurately reflects a book's contents. But what do I find when I look through the shelves at the World's Biggest Bookstore here in Toronto? Recycled confusion, badly organized hype, and people trying way too hard to be gurus.
Shel Siegel's Object-Oriented Software Testing exemplifies the last of these sins. I should have been warned off by the blurb on the back, which describes Siegel as "a quality degapper" (whatever that means), or by the introduction, which begins, "You read this book differently than you read other technical books. This book is a system." But no, I had to spend $50 to find out how badly the author wants people to believe he's a deep thinker.
The approach Siegel takes is briefly entertaining. He describes testing procedures using the terminology and concepts of object-oriented programming -- a test script is-a optimization approach, a class-object test script is-a test script, and so on. However, what useful advice he offers on structuring code for testing, and on different types of tests, is drowned in "Vision" and "Leadership" statements. I read whole pages without knowing what point they were trying to make, or whether they were trying to make a point at all.
Richard Lee and William Tepfenhart's UML and C++ was, in contrast, such a relief that it took me a while to realize that its title is somewhat misleading. The Unified Modeling Language, or UML, is a proposed standard for object-oriented class and interaction diagrams that unifies several popular existing notations. I picked up UML and C++ because I found the draft standard hard going, and the "official" books from the UML's inventors are still (as I write this) being written.
Disappointingly, much of UML and C++ appears to have been written around, rather than about, the UML. For example, the authors talk about "object interaction diagrams" and "event trace diagrams," and only mention parenthetically or in a footnote that the UML calls these "collaboration diagrams" and "sequence diagrams," respectively. The authors' real focus is on their own object-oriented analysis and design methodology. I found this reasonably interesting -- I've only been using C++ for two years, and still have a lot to learn about how to design object-oriented programs -- but Lee and Tepfenhart don't seem to know whether they are trying to teach OO analysis to beginners or to compare their methodology with others for the benefit of experienced practitioners. And every once in a while, I tripped over an unwelcome attempt at profundity, such as:
If you take the Eastern, or Taoist, approach to object-oriented analysis, you will...not be concerned with the specific application that you are implementing...
or:
...Taoist philosophy tells us to focus on capturing the objects in the problem domain rather than on the objects that will help us solve the immediate problem.
Sadly, the authors don't tell us what Catholic or Sunni philosophy has to say about programming. It probably has something to do with the sinfulness of goto statements...
Norman Fenton and Shari Pfleeger's Software Metrics shows what good technical writing can be. Software Metrics is not just a thorough, readable survey of the various proposals that have been made over the years for measuring the characteristics of programs; it is also a detailed critique of the sloppy way in which people have tried to use such measurements to predict how much effort would be required to develop and maintain software, and how reliable that software would be.
The first part of Software Metrics introduces the fundamentals of measurement theory. What does it mean to measure something? What kinds of measures are there, and -- more importantly -- what kinds of conclusions can we draw from different kinds of measurements? The second part of the book looks at software measurement in particular. Popular measures (COCOMO, function points, cyclometric complexity, and the like) are all described, and their weaknesses pointed out. Again and again, the authors show that the proponents of various metrics have failed to validate their metrics in even the most basic ways, and that many of their conclusions are, therefore, invalid. While writing this review, I read a prime example of what they are criticizing in the June 1997 issue of C++ Report. In fewer than ten pages, an author commits almost all of the crimes that Fenton and Pfleeger describe, and earns plaudits from the journal's editor for doing so.
Part Three looks at implementing software measurement in the workplace, and includes an interesting discussion about the nature of empirical research in software engineering. The book closes with a comprehensive annotated bibliography. If you have ever thought about measuring the progress of a software project, or about trying to predict the effort required to develop or maintain a program, this book will tell you what is feasible, what is just hype, and how to tell the difference between the two.
Mark Lutz's Programming Python is an equally good book, although very different in tone and approach. Python is a scripting language, similar in design and purpose to Perl, Tcl, and Visual Basic. It is well structured, with object orientation built in from the beginning, is freely available, and runs almost everywhere.
I hope that Programming Python will help win Python many new converts. Like most O'Reilly & Associates books, it is well written, superbly edited, and informative. Lutz introduces the Python language and its major libraries (of which there are many), and shows how to embed Python in C and vice versa. There are many example programs, all clearly explained, and a CD-ROM with the whole Python release for Windows, Macintosh, and UNIX.
Despite its good qualities, Python is, and probably always will be, an example of Parkinson's Other Law, which states that "Perfection is achieved only at the point of collapse." Python appeared on the scene after its competitors were already established. It is my personal favorite among "glue" languages (a term attributed to John Ousterhout, who talks about the relative productivity gains due to OO and glue at http://inwww.sunlabs.com/people/john.ousterhout/scripting.html), and, if it had existed in 1985, its competitors would probably never have gotten off the ground, but its advantages are not so great as to persuade the hundreds of thousands of VB, Perl, and Tcl programmers out there to switch.
Finally, I came across Computing Tomorrow, edited by Ian Wand and Robin Milner, by accident, and am glad I did. Computing in the United States is fairly insular: Except for a few big-name events like the Japanese Fifth Generation Project, American programmers pay little attention to developments overseas. This collection of essays by prominent British computer scientists is, therefore, a refreshing introduction to alternative perspectives.
Most of the contributions were both informative and entertaining. Among these were Gazdar's discussion of the state of natural language processing, and Needham's acerbic look at the history of network design.
While the Cambridge Ring network might not be familiar to many American readers, Needham's observations on the paradigm gap between those who think that networks should behave like telephones and those who think of them as buses will probably continue to ring true ten years from now.
Even better were Littlewood's look at the meaning of software dependability and Peyton Jones' essay on how scaling up research projects to meet the demands of real use can lead to new research problems. Littlewood's contention is that software is not like other products of engineering, and so its reliability cannot be assessed using the methods developed for such things as metal fatigue. Software is "pure design," and software faults are almost always design faults. The study of software reliability should therefore look more at how people communicate than at code-based prediction of errors per thousands of lines of code.
Peyton Jones' closing essay, "On the Importance of Being the Right Size," should be read by every academic doing computer systems research, and (more importantly) by every member of the funding bodies that give such people their research grants. Drawing on his own experience with functional languages, Peyton Jones argues that the lessons learned from small research projects can be misleading, and that wholly new research topics can arise in the course of scaling up a compiler, an operating system, or a user interface to handle real-world issues.
Some of the other essays, which were condensed tutorials on topics such as algorithmic complexity, were a bit frustrating, since 20-odd pages isn't enough space to get a big idea across to anyone who doesn't already understand it. However, the many individual insights buried in these chapters still made them worth browsing.
DDJ