Confessions of an Efficient Coder

The occupational risks of working with computers are a hot topic lately. Glare, ambient noise, ELF, carpal tunnel syndrome -- all are proving to be excellent fodder for journalists in search of an inflammatory headline, or lawyers in pursuit of a down payment on a Maui condo. One of the less glamorous (and therefore rarely mentioned) occupational risks is that, rather than having your hands stiffen up like a mummy, or getting fried by CRT radiation, you might simply disappear from view beneath the relentless onslaught of junk mail. If your mailbox looks like mine, you receive upwards of 20 catalogs a week from mail-order firms hawking everything from SIMMs to cardboard diskette mailers, perhaps twice that many "special offers" from magazines that you either already subscribe to or wouldn't be caught dead reading, a wastebasketload of invitations to seminars on object-oriented programming, and a fistful of promotional pieces for high-priced "insider" newsletters.

After 20 years in the programming business, my resistance to all of these marketing weapons is pretty well developed, even hypertrophied, perhaps, but I must confess that I still occasionally succumb to the blandishments of the newsletter tycoons. Their pitch is so seductive -- they rub shoulders with the Captains of Industry, they have the experience and insight to put the Big Picture together, they are armed with a word processor and a laser printer, and for a limited time only you can join a select group of discerning subscribers and receive priceless predigested wisdom by first-class mail. Please fill in your credit card number and expiration date in the blanks below, and be sure to include a phone number where we can reach you during business hours in case you don't have enough room left on your credit limit.

Naturally, since there are no magic answers in an industry based on the laws of physics, an endless supply of silicon, and the frail logical abilities of carbon-based programmers, very few of these newsletters pan out to be worth anywhere near their cost in unique perspectives or information. The two conspicuous exceptions are Esther Dyson's Release 1.0, which is distinctive for its droll humor and the cosmic character of its analyses, and Michael Slater's Microprocessor Report, which is unexcelled among newsletters in its timeliness, accuracy, depth of coverage, quality of writing, and production values. As for the others, well ... suffice to say that Dyson's and Slater's newsletters are the only ones that I've ever actually renewed.

Nevertheless, hope springs eternal, as the saying goes, and recently when I was feeling particularly flush I threw caution to the winds (and my budget to the wolves) and signed up for a year's worth of Ed Yourdon's American Programmer. I'd been looking at Yourdon's flyers for at least a year or so, but the promotional incentive that finally tipped the balance for me was Yourdon's promise to throw in a selection of his technical reports, one of which was called "The 68 Best Software Books." I'm a confirmed computer book junkie -- I've never managed to walk out of the famous Computer Literacy Bookstore in Sunnyvale without a tab in the three digits -- and I'm exceptionally vulnerable to someone who promises me a highly specific list of neat new books to buy.

As it turns out, Yourdon's newsletter might be more aptly named "American Administrator" instead of American Programmer. What Yourdon views as programming, you and I would consider the tedious paper-pushing of burned-out middle managers; what you and I enjoy as the creative labor of programming, Yourdon dismisses as an implementation detail that is better left to zillion-dollar CASE tools and code generators. His monograph "The 68 Best Software Books" reflects this bureaucratic orientation as well. He actually comments, at one point, "Why would anyone want to read a programming book? They tend to be deadly dry and boring, and the idea of actually reading one is enough to instantly put programmers and non-programmers alike to sleep." This follows naturally from Yourdon's conviction that programmers are merely drudges, and the real thinking happens at the managerial level.

None of the dozen or so books that I insist on having within easy reach of my keyboard at coding time are on Yourdon's list at all: Knuth's Art of Computer Programming, Tanenbaum's Operating Systems, Sedgewick's Algorithms, Kernighan and Ritchie's C Programming Language, Foley and Van Dam's Computer Graphics, Hennessy and Patterson's Computer Architecture, and so on. Instead, Yourdon endorses a collection of ethereal, academic works on software engineering and structured design, leavened by a sprinkling of New Age titles with only the vaguest relationship to programming: Sculley's Odyssey, Pirsig's Zen and the Art of Motorcycle Maintenance, Minsky's Society of Mind, Weizenbaum's Computer Power and Human Reason, and McCorduck's Machines Who Think. It's definitely grounds for alarm when one's perspective is in such blatant conflict with that of a famous guru such as Yourdon. So I was relieved to find that his list and mine are not totally disjoint. He singles out Jon Bentley's More Programming Pearls, one of my all-time favorites, for an especially warm commendation.

Bentley's Programming Pearls and More Programming Pearls books are anthologies of his "Programming Pearls" columns in Communications of the ACM, 1983 through 1987. The columns-turned-chapters have been reworked to various extents with bug fixes, additional material, and new exercises (don't cringe, even Bentley's exercises and suggested solutions are entertaining reading), but still retain their original chatty flavor. Although the chapters can be read alone, they are broadly grouped into several categories -- programming fundamentals, performance, tricks of the trade, I/0, and algorithms -- and have a greater impact if read in sequence. I particularly recommend the sections on code tuning, profilers, back-of-the-envelope calculations, "little languages," and spelling checkers. Sample these, and you'll be a Bentley fan for life.

The book Writing Efficient Programs is quite different. Although many of its points are restated in the later Pearls books, it is more structured, more cohesive, and somewhat more formal. It amounts, in fact, to a comprehensive overview of optimization techniques -- from loop unrolling to lazy evaluation to table lookups -- that can be assimilated in just a few hours, with an extensive bibliography to direct you to further reading as needed. In the "Preface," Bentley sets out his premises as follows:

The rules that we will study increase efficiency by making changes to a program that often decrease program, clarity, and robustness. When this coding style is applied indiscriminately throughout a large system (as it often has been), it usually increases efficiency slightly but leads to late software that is full of bugs and is impossible to maintain. For these reasons, techniques at this level have earned the name of "hacks." It is hard to argue with this criticism: although solid work has been done in this domain, much work at this level is pure and simple hacking in the most pejorative sense of that term.

But writing efficient code need not remain the domain of hackers. The purpose of this book is to present work at this level as a set of engineering techniques. The following are some of the differences between hacks and engineering techniques:

Hacks are applied indiscriminately; engineering techniques are applied in a well-defined context. While the medicine man peddles snake oil on the street, the physician treats a patient only in a well-defined relationship. The extreme measures of the surgeon are taken in a well-staffed and well-equipped hospital, and only when the patient needs surgery.

Hacks are described loosely and informally; engineering techniques are described precisely.

Hacks are created after a moment's thought; engineering techniques are firmly based on scientific principles and are well tested in both laboratory and applied contexts.

Hacks are passed on by word of mouth, at best; engineering techniques are described in a common literature and are referred to by name when applied. Hacks are described out of context; engineering techniques are presented with indicators and contra-indicators for their application.

Hacks are applied without certainty; engineering techniques can be tested for their appropriateness and effectiveness.

Victor Vyssotsky enhanced a FORTRAN compiler in the early 1960s under the design constraint that compilation time could not be noticeably slower. A particular routine in his program was executed rarely (he estimated during design that it would be called in about one percent of the compilations, and just once in each of these) but was very slow, so Vyssotsky spent a week squeezing every last unneeded cycle out of the routine. The modified compiler was fast enough. After two years of extensive use the compiler reported an internal error during compilation of a program. When Vyssotsky inspected the code he found that the error occurred in the prologue of the "critical" routine, and that the routine had contained this bug for its entire production life. This implied that the routine had never been called during more than 100,000 compilations, so the week Vyssotsky put into prematurely optimizing it was completely wasted.