Dr. Dobb's Journal July 1998
Displacement is a wonderful thing. I'm two months away from the next major release of the product I'm responsible for, I have a training course on software engineering for scientists and engineers to write, and what am I doing? I'm watching Working Model (http://www.workingmodel.com/) simulate a stepping gear called a "Geneva wheel." Working Model is a GUI version of first-year physics: Arbitrary shapes can be sketched, connected, given physical properties such as mass and elasticity, and then set in motion to interact according to F=ma and, um, gosh, it's been a long time since I did physics, hasn't it?
Once I've finished playing with gears, I'm going back to LCSI's MicroWorlds (http://www.lcsi.ca/), a multimedia version of the Logo educational programming environment. Logo is interactive, forgiving, and graphical, so that children can easily create and explore. In a better universe, it would have revolutionized the way computers are used in schools. This latest incarnation adds sound, web publishing, and a multitude of other new features, without obscuring its central simplicity. If you want your children to learn how to think with their computers, instead of just treating it as TV with hyperlinks, then MicroWorlds is definitely worth a look.
A couple of hours with either of these programs is enough to make most programmers ask themselves, "Why aren't my tools this easy to use?" According to the contributors to Software Visualization, edited by John Stasko, John Domingue, Marc H. Brown, and Blaine A. Price, part of the answer is that we make far too little use of interactive 2D and 3D graphics. Even the most advanced integrated-development environments (IDEs) are built around a text editor. It might highlight syntax and it might be accompanied by some list boxes or trees showing files and classes, but it's still just vi on steroids. If you compare this to the dozens of sketches that programmers draw to show data structures, inheritance, and control flow, you can see how much more we could be doing.
Computer-aided software engineering (CASE) tools have tried to integrate structured diagrams into IDEs. (A good entry-level example is Stingray's Visual CASE, at http://www.stingsoft.com/vcase/.) Most of the systems discussed in Software Visualization take the opposite approach, and try to use visualization to examine or explain existing programs. Some of the results leave me cold, but some, like the classic "Sorting Out Sorting" by Baecker et al., are as illuminating as Working Model's gears.
Of course, most contributions fall somewhere between these two extremes. The code-maintenance visualizer by Eick et al., for example, shows source files as strips, then color codes them line by line to indicate how frequently or recently they have changed. The resulting display would be a useful adjunct to a source-code control system, but its utility is limited by the fact that it reports changes to physical structure (lines), rather than logical structure (classes or methods). Still, like many other chapters in the book, it is an interesting starting point for further development, and provides a glimpse of what your next programming environment might look like.
Mark Murphy's C/C++ Software Quality Tools is a nice complement to this, since it looks at what your current programming environment ought to provide, but probably doesn't. According to the blurb on the back of this book, Murphy has worked on software quality assurance since 1990; judging from the book's clarity and common sense, I would have guessed that he'd been in the business much longer.
Along with three introductory chapters, two chapters on testing in general, and a brief concluding chapter, Murphy gives us one chapter on each of six different quality-assurance tools. The first of these is a home-brewed version of the assert() macro. This doesn't extend the functionality of the standard C++ assert() by much, but even experienced programmers will learn a few things from Murphy's discussion of when and how to use assertions.
The second tool he describes keeps track of dynamically allocated memory, and reports both out-of-bounds writes and memory leaks. Commercial varieties of such tools, such as Purify (http:// www. rational.com/products/purify/) and BoundsChecker (http://www.numega. com/ products/cc/screen_cb.htm), are taken for granted by most professional programmers, but this is the clearest explanation I have ever seen of how they work, and what they can and cannot do.
The third, fourth, and fifth chapters on tools describe an automatic test-case generator, a scripting language that can be used to drive tests, and a coverage tool that keeps track of which statements and branches in a program have been executed. All of these ought to be as widely known and widely used as the memory checkers discussed in the previous paragraphs; but because testing is a low-status occupation, they are ignored by most educators and professionals (see http://www.ddj.com/oped/1997/ wilson.htm).
The last of Murphy's tool-oriented chapters describes a tool for capturing and replaying keystrokes and mouse movements, so that GUI testing can also be automated. Some people question the effectiveness of automated testing (see http://www.stlabs.com/testnet/docs/ snakeoil.htm, for instance), but the tool itself is still worthy of study.
As good as it is, C/C++ Software Quality Tools does have one major weakness, which is its use of a home-grown scripting language as a test driver. Several well-documented, extensible, general-purpose scripting languages are widely used today, including Perl, Tcl, and Python. Any of these would, in my opinion, have been a better choice for Murphy than developing his own. What's more, the test generator and coverage tool would both be easier to extend or retarget if they had been written in one of these higher-level languages, rather than in C or C++. Despite this, and a lack of exercises and sample problems, this book would be a solid text for an undergraduate course on quality assurance.
I've been working my way through three new books on the language during the past few weeks, and have been impressed by all of them. Nigel Chapman's Perl: The Programmer's Companion and Jon Orwant's Perl 5 Interactive Course are both tutorials. At nearly 300 pages instead of Orwant's back-breaking 900, Chapman's book is thinner and more discursive, but contains neither self-quizzes nor exercises. Orwant's book, in contrast, describes Perl a snippet at a time, and has hundreds of multiple-choice questions and exercises. Orwant also goes into a lot more detail when discussing widely used Perl modules for process management, database access, and networking. I would recommend Chapman to Perl newcomers and Orwant to those who need to master the language, but given Chapman's lack of exercises, Orwant is probably a better buy either way.
Like Scott Meyers' Effective C++, on which it is modeled, Joseph Hall's Effective Perl Programming is not for the faint-hearted. Sixty items, grouped into 10 sections, cover everything from the difference between undefined and empty lists, through different ways of reading from a stream, to using the debugger effectively and submitting modules to the Comprehensive Perl Archive Network (http://www.perl.org/CPAN/, and many mirror sites). While the book is in some ways an indictment of Perl's quirkiness -- if the language had fewer syntactic and semantic inconsistencies, the book could be a lot shorter -- it ought to be in the stack underneath every serious Perl programmer's coffee mug.
The last of this month's books is Robert Glass's Software Runaways: Monumental Software Disasters. In this book, Glass looks at large projects that have spiralled out of control and subsequently failed. He states his thesis early:
...the most common problem in building software systems is not the construction of them itself, but rather the estimation of the costs of that construction. Why is there such a problem? Because the software field has not made a conscientious effort to develop histories of past project costs.
He then summarizes the findings of studies done in 1989 and 1995. Not surprisingly, failed projects tend to be those that were overly ambitious, for example, and project failure usually has several causes, rather than a single dominant cause. At the same time, using packaged software instead of rolling your own doesn't appear to reduce the risk of project failure, but using new technology (or technology that is new to the organization responsible for the project) greatly increases the risk.
If the bulk of the book was devoted to this sort of summarization and analysis, I would probably add it to my recommended reading list. Unfortunately, most of the rest of the book consists of reprints of articles about particular runaway projects, including the Denver airport baggage handling system, the FAA's next-generation Air Traffic Control system (which replaced single keystrokes with 12 or more mouse clicks), and Bank of America's MasterNet. Some of this is interesting, but only some, and only somewhat. Still, if it is not a step toward developing the history of past project costs that Glass says our profession needs, it is at least a signpost in that direction.
DDJ