By the Numbers
A copy of Trustworthy Systems Through Quantitative Software Engineering, by Lawrence Bernstein and C.M. Yuhas (ISBN 0471696919) recently flew over the transom. I had some trouble opening this one, if only because "Trusted Computing" has poisoned the namespace, but they use "trustworthy" with its original sense of reliability or responsibility.
The book forms the basis of an undergraduate course at Stevens Institute of Technology and thus lacks the encrustation of Greek variables often decorating higher level academic tomes. What it does have are many, many case studies, historical notes, and examples of how projects both succeed and fail. That seems a proper trade-off, as a preoccupation with mathematical formalism often masks a woeful lack of real-world applicability.
They observe that "Most current software theory focuses on its static behavior by analyzing source listings. There is little theory on its dynamic behavior and its performance under load. [...] Software engineers cannot ensure that a small change in software will produce only a small change in system performance."
The design of a program, unlike that of a physical gadget, is essentially the program itself. The tantalizing prospect of executable specifications means that the design becomes the program, ideally without human intervention. Given complete specifications and a good design, the program should work correctly, right?
"Magic Number!" boxes throughout the book summarize important values, one of which notes that "Only 40-60 percent of the system requirements are known at the start of the project. The rest emerge from studies of system use."
Unlike a construction project, where you can compute the effect of moving ever-so-many cubic yards of earth from here to there, a software project manager simply cannot estimate the effect of a seemingly small specification change. When the sum total of those changes equals the original specs, it's a wonder that any software projects reach a successful conclusion!
Another interesting aspect of software projects is that they tend to outlive the tools used to produce them. A recent foray through my heap of code showed that essentially none of it could be compiled today without significant changes, even for programs written in nominally standard languages. Large-scale projects with careful attention to portability may fare better, but I'm sure every organization has at least one "read-only" program in regular use: None dare meddle lest it seize up.
The design documentation for a software project often falls by the wayside, being relegated to three-ring binders in somebody's office. Fast-forward two decades: The guy retires and those binders quietly vanish, either into the dumpster or to his shelves at home as a memento.
Online documentation seems to offer a way out of that trap, but once again software's evanescent nature works against you. Two decades ago, Wordstar seemed like a good bet for a permanent document standard and, if not, then surely WordPerfect. Trust your doc to a proprietary program, fast-forward two decades, and you're sunk.
In short, read the book to get an overview of how tough software design really is. I hold that "software engineering" will remain an oxymoron until project managers can make quantitative trade-offs based on real numbers, which is certainly not true today.
