While doing some spring cleaning, I came across some old computer books that I had lovingly saved. These are all "classics", and while they're unquestionably dated, I believe their "message" (as opposed to their "content") are still relevant today. Indeed, I felt it a shame that these books should be relegated to the dustbin of history and decided to do some mini-reviews in case they piqued somebody's interests.

Despite their age, all of the books are available from the likes of Amazon.com. Whether they're available in Thailand or not I don't know, but I doubt it. If you're interested enough to browse but not to buy, you might want to check out some university library. My guess is that the Asian Institute of Technology (AIT) library at Rangsit would be the best bet given their technically-oriented library and their computer science program, but it's still a long shot.

Brooks, Frederick P., "The Mythical Man-Month: Essays on Software Engineering", Reading, Mass.: Addison-Wesley Publishing Company, 1975, 195 pp. (figure 1)

This is a true classic of software engineering. Brooks headed the team at IBM that created the operating system for the IBM System/360 mainframe computer in the 1960's. Representative of most large programming efforts, the OS/360 project was fraught with difficulties and this book was intended as a post-op dissection of the problems faced and mistakes made.

Brooks' central tenet is that large programming projects differ radically from smaller ones, the overriding problem being the management of the personnel involved. He outlines an ideal 10 person programming team suited for tackling small programming jobs and explains how this ideal team cannot simply be extrapolated to tackle larger jobs (a common temptation) without unexpected and often undesirable results. He cites numerous examples culled from his OS/360 experiences to pinpoint the pitfalls.

If you are a software manager or are dependent on one, or are involved in a large IT project, this is recommended reading. The book isn't intended for programmers per se nor is it particularly easy reading for lay readers - far from it.

(Note: Microsoft Press also publishes a series of software engineering texts, based presumably on their ample experience in this field.)

Kernighan, Brian W. and Plauger, P.J., "The Elements of Programming Style" (2nd edition), New York: McGraw-Hill Book Company, 1978, 168 pp. (Figure 2)

Folks familiar with W. Strunk and E.B. White's "The Elements of Style" will no doubt be struck by the similar titles. This is no coincidence and Kernighan and Plauger (hereafter, "K&P;") admit to having been strongly influenced by the clarity and brevity of Strunk and White's book.

The objectives of the book are clearly stated in the the first paragraph of the Preface:

"Good programming cannot be taught by teaching generalities. The way to learn to program well is by seeing, over and over, how real programs can be improved by the application of a few principles of good practice and a little common sense. Practice in critcal reading leads to skill in re-writing, which in turn leads to better writing."

When I was in college in the early 1970's, I took a course which covered a cornucopia of programming languages (Assembler, Fortran, Cobol, Algol, PL/I, Snobol, LISP, APL, etc.). Given the diverse programming styles contained in these languages, it was clear that I needed to learn certain language-independent habits which could be carried over to any and all programming languages. This is the gist of K&P;'s book (alas, it came out long after I had graduated).

The reader is taken through examples of both good and bad programming, and is advised with a follow-on "do" or "don't". While many these tips may seem obvious today, it should be noted that the concept of "structured programming" at that time was still a raging debate. Some "do" and "don't" examples:

• Write clearly - don't be too clever.
• Avoid temporary variables.
• Write clearly - don't sacrifice clarity for efficiency.
• Use parentheses to avoid ambiguity.
• Choose variable names that won't be confused.
• Use the good features of a language; avoid the bad ones.
• Make your programs read from top to bottom.
• Modularize. Use subroutines.
• Don't patch bad code - re-write it.
• Write and test a big program in small pieces.
• And many, many more ...

It's possible that today's readers will be put off by the book's use of examples rooted in the Fortran and PL/I languages (less so for me, since I was conversant with both). Nevertheless, the examples are easy to decipher and mostly applicable to the current crop of programming languages. Self-taught programmers should especially take these lessons to heart.

Kernighan, Brian W. and Plauger, P.J., "Software Tools", Reading, Mass.: Addison-Wesley Publishing Company, 1976, 338 pp. (Figure 3)

Another famous read by K&P.; (If you haven't guessed it already, these two are a pretty famous pair.) In a way, this is a continuation of K&P;'s "Programming Style" book. While the first book highlighted lessons learned from the writing of disparate programs, the second book took these lessons to heart in developing building block "software tools".

At the time this book was written, the debate over structured programming had already been resolved and the authors were free to espouse these precepts. But rather than unilaterally choosing a particular language, the authors relied on a pseudo-language called Ratfor ("Rational Fortran" - a structured Fortran without line numbers) in developing the tools. Ratfor never caught on and was superceded by other languages such as C and Pascal. The authors themselves admitted that Ratfor was modeled after Dennis Ritchie's C language and that the tools described in the book had their equivalents in the Unix operating system. Originality, of course, was not the objective here. The purpose of the book was to employ good programming habits in developing tools which could work cooperatively. Hopefully, the lessons learned from this "project" would provide a foundation for future endeavours.

This is a much harder read than K&P;'s first book and I don't recommend it for neophyte programmers. Indeed, K&P; feel it is best used as part of a second college course in programming or a course in software engineering. It should be noted that a later revisionn of this book substituted Pascal for Ratfor as the base language for the software tools, apparently in recognition of Pascal's growing popularity.

There's another book by P.J. Plauger worth mentioning. Unfortunately, I don't have it and have never read it (although I have read individual articles):

Plauger, P.J., "Programming on Purpose: Essays on Software Design", Prentice-Hall, 1993, 236 pp.

This is a compendium of articles written by Plauger for his column in Computer Language magazine. As the title suggests and in light of his past writings with Brian Kernighan, the focus is again on software design.

Huff, Darrell, "How to Lie with Statistics", New York: W.W. Norton and Company, 1954, 142 pp. (Figure 4)

Unlike the abovementioned books, this one doesn't deal with computer matters. Nevertheless, I couldn't resist adding it here. It's a timeless piece, one which is as relevant today in the year 2000 as it was in the 1970's when I bought the book, or even the 1950's when the book was first published.

The title is entirely self-explanatory. In the words of the author:

"This book is a sort of primer in ways to use statistics to deceive. It may seem altogether too much like a manual for swindlers. Perhaps I can justify it in the manner of the retired burglar whose published reminiscences amounted to a graduate course in how to pick a lock and muffle a footfall: the crooks already know these tricks; honest men must learn then in self-defense".

"The secret language of statistics, so appealing in a fact-minded culture, is employed to sensationalize, inflate, confuse, and over-simplify. Statistical methods and statistical terms are necessary in reporting the mass data of social and economic trends, business conditions, opinion polls, the census. But without writers who use the words with honesty and understanding and readers who know what they mean, the result can only be semantic nonsense."

In this age of self-serving politicians, biased journalists, advertising shysters, and other personna of questionnable ethics, this book is absolutely essential. Despite its age, I'd recommend a thorough read-through and even its purchase. It's very easy reading. If nothing else, it's eminently useful as a counter whenever the BSA spouts its voodoo statistics on software piracy.

"There three kinds of lies: lies, damned lies, and statistics" (Benjamin Disraeli).