Epilog to the First Edition
An interview with the author seemed, at the time, to be the best conclusion for the first edition of this book. It still describes the book, so here it is, once again.
Q: Thanks for agreeing to do this interview.
A: No problem — my time is your time.
Q: Seeing how these columns already appeared in Communications of the ACM, why did you bother to collect them into a book?
A: There are several little reasons: I’ve fixed dozens of errors, made hundreds of little improvements, and added several new sections. There are fifty percent more problems, solutions and pictures in the book. Also, it’s more convenient to have the columns in one book rather than a dozen magazines. The big reason, though, is that the themes running through the columns are easier to see when they are collected together; the whole is greater than the sum of the parts.
Q: What are those themes?
A: The most important is that thinking hard about programming can be both useful and fun. There’s more to the job than systematic program development from formal requirements documents. If this book helps just one disillusioned programmer to fall back in love with his or her work, it will have served its purpose.
Q: That’s a pretty fluffy answer. Are there technical threads tying the columns together?
A: Performance is the topic of Part II, and a theme that runs through all columns. Program verification is used extensively in several columns. Appendix 1 catalogs the algorithms in the book.
Q: It seems that most columns emphasize the design process. Can you summarize your advice on that topic?
A: I’m glad you asked. I just happened to prepare a list before this interview. Here are ten suggestions for programmers.
Explore the design space of solutions. Look at the data.
Use the back of the envelope. Exploit symmetry.
Design with components.
Build prototypes.
Make tradeoffs when you have to. Keep it simple.
Strive for elegance.
The points were originally discussed in the context of programming, but they apply to any engineering endeavor.
Q: That raises a point that has bothered me: it’s easy to simplify the little programs in this book, but do the techniques scale up to real software?
A: I have three answers: yes, no and maybe. Yes they scale up; Section 3.4 [in the first edition], for instance, describes a huge software project that was simplified down to “just” 80 staff-years. An equally trite answer is no: if you simplify properly, you avoid building jumbo systems and the techniques don’t need to scale up. Although there is merit in both views, the truth lies somewhere in between, and that’s where the maybe comes in. Some software has to be big, and the themes of this book are sometimes applicable to such systems. The Unix system is a fine example of a powerful whole built out of simple and elegant parts.
Q: There you go talking about another Bell Labs system. Aren’t these columns a little too parochial?
A: Maybe a little. I’ve stuck to material that I’ve seen used in practice, and that biases the book towards my environment. Phrased more positively, much of the material in these columns was contributed by my colleagues, and they deserve the credit (or blame). I’ve learned a lot from many researchers and developers within Bell Labs. There’s a fine corporate atmosphere that encourages interaction between research and development. So a lot of what you call parochialism is just my enthusiasm for my employer.
Q: Let’s come back down to earth. What pieces are missing from this book?
A: I had hoped to include a large system composed of many programs, but I couldn’t describe any interesting systems in the ten or so pages of a typical column. At a more general level, I’d like to do future columns on the themes of “computer science for programmers” (like program verification in Column 4 and algorithm design in Column 8) and the “engineering techniques of computing” (like the back-of-the-envelope calculations in Column 7).
Q: If you’re so into “science” and “engineering”, how come the columns are so light on theorems and tables and so heavy on stories?
A: Watch it — people who interview themselves shouldn’t criticize writing styles.