American Scientist

To the Editors:

Decades of experience teaching software engineering and supervising software development life cycles compel me to counter three of the many interesting opinions expressed by Greg Wilson and Jorge Aranda in “Empirical Software Engineering” (November–December).

First, the authors write that software complexity metrics, such as McCabe’s metric, provide little more information than counting lines of code. But such metrics do reflect the difficulty of writing, debugging, testing, understanding and operating a program. They help users and future personnel understand operational issues and they provide the management with useful insight into the program. Also, optimizing complexity by only reducing line count sometimes increases complexity by increasing the logic load. Reduction by one line of code does not reduce complexity; reduction by one logic operator does.

Second, the authors’ emphasis on coding in pairs is misplaced. It is more important that code be tested independently and that coding be a small part of the life-cycle costs that also include functional analysis, designing, coding, testing and debugging, to name a few. All these activities make software more understandable for managers, users and future personnel.

Finally, the article dismisses the importance of data flow diagrams and structure charts. Yes, code can be written without these steps, but doing so invariably results in poor structure for long programs. Documented design is important for a multitude of issues discussed in my textbook Software Systems Engineering (1992) and similar texts. The benefits range from controlling life-cycle costs to managing team interaction.

Sam Pierce
Los Angeles, CA

Drs. Aranda and Wilson respond:

Sam Pierce points out that attempting to minimize source-code complexity by reducing the number of lines of code may be counterproductive. This observation is true, but it is a misreading of the implications of the research we discuss. Israel Herraiz and Ahmed Hassan found that simple line counts are as good a measure of complexity as the more sophisticated metrics we have, not that they are an appropriate target of improvement efforts. In other words, large line counts are merely symptoms of code complexity, and reducing the line count itself will not make the complexity go away, just like reducing a patient’s fever will not rid him of disease. Line counts are an imperfect measure, of course, but the rest of our complexity measures are, sadly, just as problematic.

Pierce’s assertion that code written without documented design “invariably results in poor structure for long programs” conflicts with many available examples of good software projects built without a heavy up-front investment in design. Some very good programmers believe that plunging into the code, with constant refactoring and a minimum of design, is the best way to develop software. This debate in our field has been long and (so far) fruitless. One of the points of our article is that, until we move beyond anecdotes and collect strong evidence in favor of a particular approach, we should be less dogmatic about our methods.