By Jack Ganssle

Code Books

Published 12/14/2001

Tom DeMarco, noted software guru and wag, complains that "programmers don't read." In an attempt to get some quantitative data we ran a poll a few months ago (http://www.embedded.com/pollArchive/?surveyno=2284). 48% of respondents read more than four books in the last 6 months, a pretty impressive number.

Yet a full 21% read one or less. Perhaps this is due to the curse of TV or overstuffed lives. But surely this figure bodes ill for the future of software. This is a dynamic, evolving field; there's a constant flow of new ideas, many of which are applicable to any embedded person. Unless we keep up with these new developments, primarily by reading books, our careers will stagnate and wither.

A publisher of technical tomes recently told me he wonders if DeMarco was wrong. Instead of engineers not reading, he wondered if they can't read. We were discussing a book that was nothing more than long listings of Java with scanty English explaining the software. Sometimes it seems that modern technical books are either in the "Idiot's Guide" camp or are a dreary 1000 pages of source code, with a CD-ROM sandwiched in the back cover.

He then told me that one of the best-selling Unix books is nothing more than script listings, with virtually no prose. If that's what makes a best seller, then I cry for the future of technical writing.

Of course it is important to read code. But most of what's published in these sorts of books is awful. It's poorly documented and badly structured. Perhaps the little bit of text that accompanies the listings is there because the commenting and design is so awful. Why not write it correctly, stuff the Java on the CD, and then use the wonderful media of the printed page to convey something important?

If you like code books, check out Jean LaBrosse's two books ("MicroC/OS-II" and "Embedded Systems Building Blocks"). Both contain source listings so beautifully structured they get as close to poetry as software can be. Read these to learn how one can and should create firmware. But they are rare exceptions in what passes for computer literature.

Sometimes a long listing accompanied by an insightful explanation can teach a lot about a specific subject. More often, though, I'd suggest the readers are better served a high level flow chart or PDL. It's a much more efficient way to get the ideas across. Implementation details, if needed at all, should live on the web or the CD.

I'm just finishing Petroski's "The Pencil", 350 wordy pages about the engineering and history of this simple writing instrument. One friend who was hefting yet another book filled with listings looked at The Pencil aghast, unable to imagine how anyone could read - let alone write - so much about such a little thing. He was quite happy to turn back to his code book. So maybe I'm wrong. What do you think?