This monograph, Taming the Tiger, is critical of current software engineering and software economics practices and advocates two-phase metaprogramming, in which rapid prototyping is phase one and rapid fabrication (fixing specifications and producing the software for the tools built during the prototype phase) is phase two. This is in sharp contrast to the familiar software life cycle approach. However, it is unclear who decides the requirements and/or specifications for the first or the final prototype and how. Also unclear is how one guarantees that the metaprogramming products will meet customer requirements or guarantees before the costly final iteration of the prototyping that the final product will be what the customer originally wanted. The book seems to have been motivated by considerations of software economics and productivity. Some software quality concerns are also mentioned.
This book contains a toy program to invest a permutation [1] that is used to illustrate what Levy considers are some problems with the state of the art in software development:
(1) The difficulty in determining (much less proving) program correctness.
(2) The difficulty in retaining a link between the algorithm and the program, so that the design is not discarded when coding and/or implementation is complete.
(3) The undecidability of the equivalence of two programs with the same specification or of a program and its specification.
(4) The competence-performance dilemma arising from programs that are at the limits of human performance and therefore difficult to debug.
(5) The difficulty when the program text generally lacks information on the derivation of the program text or on the underlying principles used. This presents obstacles to understanding and debugging the programs.
Based on the preceding analysis, the author develops some principles for a methodology of program development and for the concept of primary program description (PPD). On page 3, the author states, “If we are to find a way to radically improve both the quality and productivity of programming, then we must find a way to make programming less labor intensive.” I am not sold on automation to the degree that I believe that higher quality necessarily implies less dependence on labor (and perhaps more on automation). The great success and world renowned high quality of Swiss watches is a case in point. Also, automation can be so badly done that quantity is improved at the cost of quality. The preference in the United States for cars such as the Mercedes Benz, Toyota, and Honda over some of the domestic model cars also demonstrates that “more quality and productivity--less labor intensive” is a superstition rather than an engineering principle.
The author infers (on p. 7) that design is thrown away when a program is written. This perhaps means that program hackers are not good practitioners of software engineering (e.g., the practitioners of MIL-STD-2167). The current technology offers tools like Ada, which can be used both as a program design language as well as a programming language. This commonality establishes an automatic link between a program and its design. The author’s claim (p. 8) that programmers write programs fitting the syntax of a particular programming language is not true for good practitioners of software engineering. The designer creates the design to translate his or her ideas as exactly as possible. The programming language comes much later--only after the design has passed the necessary reviews.
The author presents his concept of primary program descriptions (PPD) (pp. 16–17). However, good software engineering practitioners (i.e., practitioners of MIL-STD-2167 and of the methodologies of Yourdon, Jackson, Parnas, SREM, ISDOS, et al.), document requirements, specifications, and designs that include the deep structural information and all relevant transformations and that are understood by their intended audiences.
Chapter 2, entitled “Unifying Themes,” is an indictment of the current software engineering practices. The author cites the “failure of software engineering to solve the problems it has been addressing,” the “stagnation in software engineering,” the “lack of understanding of the programming process,” and “a growing awareness that software engineering has not accomplished what it set out to do” to support his claim.
The author leaves the impression (p. 24) that “a combination of programming languages and styles” in a software system is a hopeful sign. The problems that software engineering has perhaps unsuccessfully grappled with may be reduced or eliminated] Perhaps the author did not mean to leave these impressions in the minds of the readers. However, the perceptions created by the statements, “I also see many hopeful signs” followed by “more systems are emerging that allow a combination of programming languages and styles. . . .” make one alarmingly aware of a lack of a scientific approach in Levy’s criticisms of the current software engineering practices.
The author universally criticizes the quality of documentation and neglects all fine examples of sincere attempts to produce quality documentation. Levy’s approach to improving documentation (see the last chapter of his book) is the so-called primary program description (PPD), which is only briefly explained. In spite of the author’s blanket indictment of the several hundred methodologies in practice in the software engineering area today, I still find similarities between PPD and the methodologies under criticism by the author.
Frankly, I strongly disagree with Levy’s claim that he sees no hopeful signs for the problems of documentation. The integration of graphics modules into the toolboxes of various practitioners of software engineering is just an example of the basis for my disagreement.
The author’s criticism of the waterfall model seems to be based on economic considerations and devoid of engineering or scientific ones. He is perhaps advocating rapid prototyping without any requirements specification. We already have a lot of throw away code, and the correct approach should be to reduce the waste of resources.
The metaprogramming solution advocated in this book lacks an implementation. The tools and the good research foundation needed to develop the theory into practice are lacking. The book tends to neglect real-time programming for embedded computer systems, and that is a large portion of the kingdom of the software engineering “tiger.” In addition, it is not clear why metaprogramming should work. Some scientific evidence, rather than a few isolated small examples, is needed to make the current practitioners of software engineering throw away the tiger--their current practices--and embrace an unknown creature, metaprogramming.
