Browse Books

Reviewer: Haim I. Kilov

This description of the experience of several software groups at Eastman Kodak can be used by software developers and first-level managers who want to create or improve a software engineering culture. There are many good books of this kind, with sound advice (against hacking, for paper prototyping, against dogmatism, for incremental changes, and so on), many bulleted lists, and even fine examples. This book also enumerates useful one-paragraph “culture builders” and “culture killers” at the end of each of its 20 chapters. Articulating this information is obviously useful. The bad news is that most of these books, including this one, could have been published in the 1970s, and the best [1,2] were. Generally, the need for a strong, solid foundation in software engineering (like the one promoted by Dijkstra) is not emphasized. Although the importance of reading and study is stressed, the author does not state that some books are better than others; references to a small set of software engineering classics would be helpful for beginners. Although the author often declares that specifications are important (for example, when he states that “it would be nice to think we are beyond the stage of `don't bother with those specifications, start writing code,' but this call of the software dinosaur still echoes throughout the land”), most actual discussions and examples are concerned with writing and debugging code. Statements such as “Great programs can't compensate for a poor system architecture” (p. 247) are not always explicitly or consistently supported throughout the book. Some of the author's advice is inconsistent with these declarations. For example, on page 242, he suggests that if the code differs from the model, then the model may be unchanged or even discarded. This will probably be appreciated by future maintainers, as the year 2000 situation clearly shows. The walkthroughs, inspections, and reviews described are mostly of code. The author does not explicitly distinguish between business (problem) and system (solution) specifications. Obviously, failure to meet requirements can be determined by testing, but the failure may be discovered too late, whereas this determination can be made by inspection and validation, despite what is said in the table on page 193. The author strongly suggests that the same people (“developers”) are doing everything, from specifications to coding, which need not be the case. Measurement of anything in lines of code is misleading. Nevertheless, despite various caveats, the author describes such measurements at length. Complexity is more important than size. Measuring reuse by the number of lines of code or object classes contributed to the reusable library (p. 115) does not help either. Although the author states that requirements should be separated from solutions, the very first “use case” example (p. 8 1) is in terms of solutions: it includes entering an order number and, generally, an interaction with the computer—not a problem specification. However, the author does not say what he means by a use case, and this approach may well correspond to one of the many definitions of this term. Precision should not be introduced only at the coding level: business and system specifications can and should be precise (although less detailed than code). Unfortunately, the author does not emphasize this, although he says that “software people are notoriously sloppy about documenting requirements” (p. 84). He also does not say what good requirements are (and are not). The semantics of a program are never explicitly specified. Requirements are not equivalent to drawings; writing and reasoning about them involves much more than adding a line to a drawing. Adding such a line takes a minute or two, but understanding where to draw it may take much longer. Similarly, the concept of good quality from the beginning—the most important factor in a project's success—is not emphasized, but the author notes that “few of us…like to draw models of systems.” (Weinberg [2] was probably not the first to observe that if the system does not do what it is supposed to do, then any other qualities, such as performance, are of no importance.) Since the author believes that “it is much more fun to write code than to write documentation” (p. 152), the good advice provided elsewhere in the book seems like lip service.