A friend gave me a set of books, knowing that I am a computer geek. The books were Basic with Style, Fortran with Style, and Pascal with Style and written by Henry F. Ledgard and Paul Nagin. Dating from the late nineteen-seventies, these books summarize good coding practices of the day. We've seen a lot of changes from the days of the Apple ][ and CP/M, at least in hardware and networks. What about software development?
The books present a set of proverbs: good practices for programming.There are about twenty; we can go through them quickly.
NOTE: The three books are really one book, tailored for each language. Object-oriented programmers would say that each is a specialization of a base class. I will consider them as one book, or focus on the proverbsand not so much the individual books.
Proverb 0: "Do not break the rules before learning them." I would have phrased it "Learn the rules, then learn how and when to break them," and I think it is very good advice.
Proverb 1: "Don't Panic." Possibly lifted from the BBC radio production of "The Hitchhiker's Guide to the Galaxy," Ledgard and Nagin advise following a deliberate plan for development. They recommend avoid rushing; later they advocate top-down design and coding. Agile Development encourages a "sustainable pace". Not quite the same, but I think this proverb still holds.
Proverb 2: "Define the problem completely." I'm pretty sure the authors use this in the "requirements first, then design, then coding" sense, which is quite different from the approach used by Agile. In Agile Development, one develops the tests first and then codes. The tests define the problem for the code.
Proverb 3: "Start the documentation early." This proverb contains the assumption that there will be documentation. In Agile, the recommendation is to create only the documents that are needed.
Proverb 4: "Think first, code later." This is the authors acknowledgement of the need for design.
Proverb 5: "Proceed top-down." The authors advocate top-down programming, which requires a design. Agile lets the design grow with the program and does not mandate an up-front design. A partial match with Agile methods.
Proverb 6: "Beware of other approaches." Not content to advocate top-down design and programming, the Ledbard and Nagin warn us away from other coding approaches.
Proverbs 7 and 8: "Code in logical units" and "[Use] functions and procedures [subroutines]". The wording varies here in the three books, following the varying terms used by the different languages. But the sentiment is the same as the modern-day notions of high cohesion and loose coupling. Agile Development doesn't speak of these concepts; it allows development teams to use them as they see fit.
Proverb 9: "Don't GOTO" or "Be wary of GOTO." Here the authors argue for structured programming techniques, something that is accepted as good practice today.
Proverb 10: "Prettyprint." A term that has fallen into disuse. The authors argue for proper indentation and good use of whitespacing, concepts accepted as good practice today.
Proverb 11: "Use mnemonic names." (Not included in the BASIC version, since BASIC at the time had single-letter variable names.) Considered a basic practice today, and anyone not using good names is considered a poor programmer.
Proverb 12: "Comment effectively." The authors argue that comments should have value not merely prescence, something that is not recognized today.
Proverb 13: "Make constants constant." Later languages have good constructs for constants and most programmers (and current texts) use them.
Proverb 14: "Get the syntax correct now." This proverb assumes a non-interactive programming session and the authors mention "turn-around" time, a concept probably unknown to most programmers today. (In the days of batch computing, when you submitted a program for a run and got the results later, the "turn-around time" was the time you had to wait for your results. Interactive programs such as word processors were not possible; all data had to be supplied up front.) With today's personal computers, powerful development environments, and syntax and logic checking in compilers, I think the more effective approach is to let the computer check the syntax.
Proverb 15: "Don't leave the reader in the dust." Here the authors recognize that a program is read by humans more than it is read by computers, an observation made by Gerald Weinberg in The Psychology of Computer Programming. Agile Development advocates refactoring for readability.
Proverb 16: "Produce good output." Today we accept that the requirements will specify -- in detail -- the output. Not so in the nineteen-seventies.
Proverb 17: "Hand-check the program." Another proverb caused by long turn-around times. Instead of syntax, this proverb advocates checking the logic. Perhaps not a bad idea today.
Proverb 18: "Prepare to prove the pudding." Here Ledgard and Nagin provide weak guidance. I suspect that they created the proverbs in a top-down design and had a section for testing and verification. Later when they created the details for the section, they found that they had nothing. The only techniques the provide are "write programs that run correctly the first time" and to use Print statements to display intermediate results. Agile Development mandates automated tests for verification.
Proverb 19: "Have someone else read the work." Not a formal code review but a good start. Also notice that the authors refer to the program as "the work" not "your work", shifting ownership away from the programmer. This was called "egoless programming" by Gerald Weinberg. With Agile Development, the notion of pair programming gives us another pair of eyes.
Proverb 20: "Read the manual again." The authors advocate learning details about the language and the compiler.
Proverb 21: "Don't be afraid to start over." Advice offered by many over time. Agile Development does not advocate a complete re-design but allows it, with the automated tests providing verification support.
So how well do the proverbs hold up? Quite well, I think. Some are dated; they are tied to specific technologies like batch processing.
Which means that we had the knowledge for effective software development back in the nineteen-seventies.
Huh.
No comments:
Post a Comment