System quality through structured programming
F. T. Baker · 1972
Baker published two papers in 1972 that, taken as companion pieces, contributed significantly to the credibility of structured programming. The earlier paper, Programmer Team Management of Production Programming [Paper 7], discusses the theory of the Chief Programmer Team and describes the New York Times system in considerable detail. The following paper, System Quality Through Structured Programming, concentrates on the actual working product. Indeed, the primary reason for reading this second is that it presents real data about real bugs in a non-trivial system produced with structured programming, top-down testing, and related techniques. Because it is a real system --- the New York Times presumably paid real money for it! --- it has been used for years to help convince skeptics and cynics that structured programming actually works. Of course, people are no longer quite as impressed by a project that took place during 1969 and 1970, and there are other examples and case studies that can be used. But for quite a long time, this was the case study on structured programming. Notice, as you read, that Baker makes an important distinction between the different types of bugs found in the New York Times system. He refers to functions, functions, and functions. An incorrect function is defined by Baker as one that is implemented but that does not operate correctly: a coding error (or possibly a design error). An omitted function also could be interpreted as a design or coding error, but a misinterpreted function implies something rather different: It implies a communication problem between the user, the systems analyst, and/or the programmer. This last type of bug, the misinterpreted function, is of particular interest to me. It can occur as a result of poor specifications (for which more recent techniques like structured analysis can provide a remedy); but it also can happen even with the best specifications, simply because building a software system involves imperfect communication between human beings. Since this is the case, top-down testing, a technique that certainly was used in the Times project, is particularly important: It helps expose these misunderstandings and faulty communications as early as possible. Baker doesn't emphasize this, but it is widely recognized now. You should keep one last point in mind when you read this paper It was written after approximately two years of operational experience with the system; consequently, it does not represent the last word on the quality or reliability of the New York Times system. During the summer of 1975, several papers appeared in popular computer journals and numerous discussions were presented at computer conferences, all debating the success of the Times project. Some claimed (based on informal discussions with a few of the Times maintenance programmers) that the quality of the software was considerably lower than that suggested by Baker; others stoutly maintained that the software was continuing to run at the same high level of reliability reported by Baker in 1971. The issue never was completely resolved, and by now no one really cares. What is important to recognize is that to get a true feeling for the impact of the structured techniques on system quality, one should count the number of bugs and measure (if there is a meaningful way to do it) the ease of maintenance ten years after a system is put into operation, as well as during the first year. So, whether or not the results of the Times project were what Baker believed them to be, his early reporting gave structured programming a much-needed boost.