NEATER2: a PL/I source statement reformatter
Communications of the ACM
Flow diagrams, turing machines and languages with only two formation rules
Communications of the ACM
| Hi-index | 0.00 |
As is evident from some of the other material reprinted in this book, much of the early discussion about structured programming and the related techniques was conducted by academic people and was published in scholarly journals, thus escaping the attention of the average software professional. In the rare instances in which structured programming was brought to the attention of the realworld programmer, the subject usually was greeted with loud hoots: "Bah! Humbug! What do those academic types know about real programming? By God, they should have to write a payroll system under a tight deadline with XYZ's version of COBOL. Then they'd stop yapping!" It's precisely because of this traditionally academic association that Terry Baker's article in the January 1972 IBM Systems Journal was so important. IBM's name, for the first time, was associated with top-down design, structured programming, and the related disciplines. Granted, IBM Systems Journal is not as widely read as Datamation or Computerworld, but it attracts more readers than the proceedings of the IFIP Conferences. The article served to call popular attention to the new techniques, and, as happened with virtual memory and several other technological developments, caused a substantial number of people in the field to believe that IBM invented structured programming! Who invented structured programming clearly is debatable, but IBM's role in popularizing it is indisputable. Many of Baker's topics deserve mention, either because of their initial impact, or because of their long-term implications. The first noteworthy concept is the major topic of the paper: the Chief Programmer Team. Baker's description of the team is a good one, and is illustrated with a real case study. The fact that the concept has been expanded and refined in later works, such as Fred Brooks's The Mythical Man-Month (Reading, Mass.: Addison-Wesley, 1975), should not detract from its worth. Nor should the realization, some seven years after the article's publication, that the Chief Programmer Team concept probably will never work in an ordinary EDP organization, for the following reasons: There are precious few chief programmers. Those that do exist are very expensive, and are not interested in working on small computers and mundane applications. In short, the Chief Programmer Team concept probably will work only in companies that are in the EDP business to make a profit. In most other companies, data processing is regarded as a necessary evil, and programmers (chief and indians alike) are tolerated with the greatest reluctance. Similarly, the concept of the program librarian, discussed at length by Baker, is less popular today than when it was first introduced. The concept of a program library is an important one, and its use has indeed been accepted, but the idea of hiring a human being to create, maintain, and control the library is becoming increasingly less popular. Most of the other structured concepts discussed by Baker still are used widely. Interestingly, Baker mentions top-down testing, but seems to attach relatively little importance to it, whereas I think it is one of the most important structured techniques. Baker also mentions structured programming, of course, and refers to Böm and Jacopini as the source of the idea; what's interesting is his emphasis on the formatting of structured code, and his effort to show how structured programming works with real languages such as PL/I and assembler. The other major significance of Baker's paper relates to the so-called New York Times project. For several years following publication of the paper, programmers quoted Baker's figures as proof that structured programming increases productivity by a factor of two or five, depending on your viewpoint. Statistics from a companion paper, "System Quality Through Structured Programming" [Paper 11], have been used by many EDP professionals to prove that structured programming leads to more reliable software. Indeed, the productivity and reliability figures of the New York Times project are impressive, but one has to wonder whether the Hawthorne Effect was a factor: Were the programmers more productive because they knew they were working on a special project? Or were they more productive simply because they were extraordinarily gifted programmers? Was the success of the New York Times project the result of the people or was it because of the particular organization of the people ? Questions like these still are being debated, and they will continue to be debated for several years to come. Significantly, Baker's paper first brought the questions to everyone's attention.