The Community for Technology Leaders

Old and new


Pages: pp. 83-85

Our industry has a tradition of challenging the accepted ways of doing things. Some of the challenged leaders lose their positions. Others hold on.

Words from the masters

In this section I look at works by two of the most respected and most prolific writers in the field of computer programming and beyond.

Weinberg on Writing—The Fieldstone Method, Gerald M. Weinberg (Dorset House, 2006, 208 pp., ISBN 0-932633-65-X,, $24.95)

Gerald Weinberg has 40 published books to his credit, so I was eager to read about the techniques that work for him and have worked for many participants of his writing workshops. He describes his approach to writing as the fieldstone method. It derives from the first lesson he learned in college: write only about things you care about. As a result, Weinberg goes through life noticing what he cares about and making notes. These unordered notes are like the fieldstones you might collect to make a stone wall. He goes to great lengths to ensure that he can find these notes when he needs them. Then, when he decides that he wants to write about something, he gathers the appropriate fieldstones and builds a book or an essay the way a skilled stonemason would build a wall.

Building a wall requires you to select the right stones, organize them, and then assemble the wall—trimming and polishing to make the best wall you can with what you have. Writing by the fieldstone method requires the analogous actions, and Weinberg has developed principles and procedures for all of these. He describes them in this book, using frequent anecdotes and many exercises. These slow you down and keep you from skimming—like the chunks of celery that make you chew your potato salad thoroughly.

Weinberg shows how his methods prevent writer's block, the paralyzing affliction that can lead writers into addictive behaviors that keep them from working for weeks at a time. He regards writer's block not as a disorder in you, the writer, but as a defect in your methods. It is natural to have too few or too many ideas. The problem comes from what you do about it. Weinberg tells you to ask yourself the Goldilocks question: Is the number of ideas I have to work with too great, too small, or just right? Depending on the answer, you gather more ideas, dump some, or start trimming and polishing the ones you have.

Weinberg mixes his practical techniques with approaches we referred to as "new age" in the 1970s. One of his students writes that Weinberg offers intangibles like "motivating, raising self-esteem, building confidence in writing, considering self-other context, teaching the true meaning of discipline, thinking more clearly, and raising awareness." I'm sure these intangibles come across more powerfully in his workshops, but it is amazing how clearly they come through in this short book.

Weinberg addresses the mechanics of selecting, organizing, trimming and polishing. Here he gives excellent advice, including some practical techniques for achieving the famous dictum of Strunk and White: Omit needless words.

Weinberg addresses the difficult problem of knowing when to stop. The fieldstone method makes this easier than other approaches do. For example, if you start by developing an outline, even a minor point that you can't provide right away might keep the whole piece of writing in suspended animation. He likens this to waiting for the number that completes your card in a game of bingo. (I thought of that analogy as I read Donald Knuth's latest contribution to his magnum opus, The Art of Computer Programming.)

Other authors let their desire for perfection or their fear of criticism keep them from finishing. All of these seem silly in the context of building a fieldstone wall.

Weinberg provides useful anecdotes about his own experiences with publishers. The Psychology of Computer Programming was not his first book, but it was his first blockbuster. Aspiring writers might find it encouraging that Weinberg had difficulty finding a publisher who would take it. He persisted, and finally found a publisher. When I reread parts of that book recently, I remembered how radical they seemed in 1971. As I look around at today's programmers, I see that their underlying ethic and approach contain much from that book—even though few of them have even heard of it.

This summary is no substitute for reading the book. I have left out many good parts that are hard to summarize. For example, I'd like to steal the entire chapter on plagiarism. If you want or need to write, this book will be useful to you. It is full of practical advice that can help you succeed.

The Art of Computer Programming, vol. 4, fascicle 4, Donald Knuth (Addison-Wesley, 2006, 128 pp., ISBN 0-321-33570-8,, $19.99)

Don Knuth received the ACM Turing award in 1974, became a Fellow of the British Computer Society in 1980, was a charter recipient of the IEEE Computer Pioneer award in 1982, and received the J.D. Warnier prize for software methodology in 1989. At Stanford University, he holds the unique title of emeritus professor of the art of computer programming.

When I reviewed the second edition of volume 3 of The Art of Computer Programming ("Micro Review: Making Systems," IEEE Micro, vol. 17, no. 5, Sept.–Oct. 1997, pp. 74–76), I compared the entire work to Herman Melville's Moby Dick. I did not mean that it constitutes an obsession on Knuth's part. Rather, it is, as Moby Dick is to students of literature, a work that you should study when you begin your career and reread as the years go by. Unfortunately, this is only partially possible. Although Knuth announced six volumes in 1969, he has to date completed only three, and there is no firm schedule for the rest. In fact, his greatest accomplishment, his single-handed design, programming, and documentation of the TeX system for document preparation, intervened. He spent many years developing that tool and then spent more years using TeX to "reimplement" the first three volumes.

Knuth has now devised a scheme for publishing the remainder of The Art of Computer Programming a little more quickly. Inspired by the nineteenth-century English author Charles Dickens, who published novels in serial form, Knuth has begun to publish volume 4 in parts, or fascicles. In the last year he has brought out four such installments. The first fascicle, long-time Knuth fans will be delighted to hear, describes MMIX, an imaginary computer that replaces the 35-year-old MIX, the imaginary computer he used to describe algorithms in his original work. While MIX represented an idealized mixture of the assembly languages of 1960s-era computers, MMIX is "a RISC computer for the new millennium."

Volume 4, as originally announced in 1969, covers combinatorial algorithms. Thus, fascicles 2 and 3 deal with generating tuples, permutations, combinations, and partitions. These lead up to fascicle 4, which deals with generating trees. This fascicle also reviews the history of generating combinatorial patterns. For example, King Wen devised the I Ching in 1143 BC, and it is still a bestseller. Its 64 chapters correspond to 64 hexagrams, in which each of the six lines has one of two values—yin or yang.

I can't in good conscience urge you to rush out and buy this book (unless you're a librarian). Aside from designers of searching algorithms, most people will not find it directly relevant to their work. Nonetheless, it is important as part of a coherent encyclopedia of computer science. And there is the added incentive that Knuth will pay you $2.56 for each typo you find.

Like the monks moving the Tower of Hanoi, Knuth perseveres. I hope he lives long and prospers, and I hope he never finishes.


Here are books about new technologies that challenge accepted leaders.

From Java to Ruby—Things Every Manager Should Know, Bruce Tate (Pragmatic Bookshelf, 2006, 164 pp., ISBN 0-9766940-9-3,, $29.95)

Bruce Tate is a consultant specializing in persistence and lightweight development in Java and Ruby. He is the author of the award-winning Better, Faster, Lighter Java and several other books. He wrote this book for managers, or for developers advising managers, who are considering moving some development projects from Java to Ruby.

Java has come a long way since its introduction 11 years ago. In the June 1996 Micro Review, I described the design processes by which C++ and Java put themselves forth as object-oriented successors to C. I also wrote at the time,

I think Java will eventually replace C, but I think C++ will persist as its competitor for a long time. That conflict will probably follow the model of the RISC vs. CISC wars, so that 10 years from now it will be hard to know which is which ("Micro Review: Java," IEEE Micro, vol. 16, no. 3, June 1996, pp. 3–5).

Those 10 years have passed, and Java has acquired a lot of the complexity of C++, especially in the competing frameworks that developers must evaluate and learn to use. Meanwhile, several more nimble languages have acquired large communities of users. According to Tate, one of those languages, Ruby, in the form of the Ruby on Rails framework, presents a better solution than Java for an important class of problems: database-backed Web applications.

Tate makes the point that moving to a new computer language is risky in many ways. You should not consider it unless you see serious problems with your current situation. Tate suggests that you consider Java's greater complexity and lower productivity as risks to be balanced against the risks of moving to Ruby. He sees a large part of Java's complexity as coming from the various frameworks that Java programmers must use. He compares this with the simplicity and productivity of Rails.

Tate presents other arguments and provides greater detail. He doesn't try to decide for you, but if you opt to try Ruby, Tate provides detailed strategies for migrating and for coexisting with Java. Tate has a pro-Ruby bias, but he acknowledges that not everybody agrees with his point of view and presents the arguments on both sides. He includes the comments of many industry experts, most notably Martin Fowler, who are frustrated with Java's deficiencies.

If you are seriously considering a change of this sort, read Tate's book carefully.

Introduction to DITA—A User Guide to the Darwin Information Typing Architecture, Jennifer Linton and Kylene Bruski (Comtech, 2006, 348 pp., ISBN 0-9778634-0-9,, $50.00)

Most software products require some sort of documentation above and beyond what the bare user interface provides. Providing that documentation has traditionally been the task of technical writers, who produced manuals—printed or online books that covered the subject sequentially.

Over the last 10 to 15 years, many movements have converged upon a model of documentation that throws away the book. In this model, writers write topics—atomic pieces of information that they recombine as needed and present to users online on demand. Users press a help button specific to the task they are working on or use indexes, tables of contents, or search engines to find the topic they need. Topics typically describe procedures, but they can also explain concepts or provide reference information.

As this model has developed, writers have tried to achieve its goals by using the available book-oriented tools. In the area of structured writing, this meant using the Docbook system, which was originally developed in the 1980s to work with SGML (Standard General Markup Language, an ancestor of XML). The Docbook DTD (document type definition) is in widespread use with XML publishing tools today.

Darwin Information Typing Architecture (DITA) marks a clean break with the book model. Its designers at IBM started from topics. They introduced a system of maps to take the place of the structure imposed by a book. Maps externalize dependencies and cross references, which facilitates automated recombination and reuse of topics.

Until now, there have been few organized presentations about DITA for writers. Linton and Bruski try to fill that need. They have built their book around a complete online help system developed in DITA from the ground up. If you work your way through it, you will learn how all the pieces fit together.

Unfortunately, the book shows signs of the speed with which it was brought to market. Its structure is a combination of parts, sections, and lessons—but no chapters. It appears to superimpose a book's outer trappings onto a set of lecture notes and lab instructions. Also, the editing leaves a lot to be desired.

If you are in a hurry to understand DITA, this book can help. If not, you might want to wait for the second edition.

66 ms
(Ver 3.x)