Issue: Vol. 14, No. 4, July/August 1997 | PDF

The Programmer Writing

In 1987, Fred Brooks observed that “the gap between the best software engineering practice and the average practice is very wide—perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important” (“No Silver Bullets—Essence and Accidents of Software Engineering,” Computer, April 1987) Continuing Brooks’ line of thought in 1990, the Computer Science and Technology Board stated that the biggest gains in software development quality and productivity will come from disseminating effective practices—codifying, unifying, and distributing existing knowledge in the form of software engineering handbooks (“Scaling Up: A Research Agenda for Software Engineering,” Communications of the ACM, March 1990).

Who should write these handbooks?

In August 1837, Ralph Waldo Emerson delivered an address that came to be known as “The American Scholar” (Selections from Ralph Waldo Emerson, Edited by Stephen E. Whicher, Houghton Mifflin Company, 1960). It is one of the most inspirational essays I have read. Moreover, I believe it contains the answer to the question of who should write these software handbooks.

Emerson’s Authors

Most software development books are written by six kinds of authors: Recent retirees, University professors, Seminar instructors, Consultants, Think-tank developers, and Developers working on production software. People in each of these groups have valuable contributions to make, and it would be a mistake to discount any of them. Recent retirees bring years of experience, insight, and reflection to their writing. University professors bring a full awareness of leading-edge research. Seminar instructors have a chance to test their material in front of hundreds or even thousands of students before publishing their material in book form. Consultants see dozens of clients a year, and their observations can be based on an incredible breadth of exposure to effective and ineffective software practices. Think-tank developers at Xerox PARC, AT&T Bell Labs, and similar environments have produced some our best software engineering technology. But I think that developers working on production software must shoulder the primary burden of creating these handbooks.

In “The American Scholar,” Emerson draws a distinction between a thinker and Man Thinking (which is his synonym for American Scholar). A thinker is someone whose sole function is to think. A thinker experiences life second-hand, through other people’s books, articles, and descriptions of the active world. A Man Thinking, on the other hand, is a robust person who is active in the world, actively engaged in a trade or occupation, who occasionally pauses for reflection. The Man Thinking has a strong bias toward action. “The true scholar grudges every opportunity of action past by as a loss of power. It is the raw material out of which the intellect molds her splendid products.” Emerson argues that the direct experience of Man Thinking is critical to genius, and that genius can emanate only from a Man Thinking, not from a mere thinker.

Emerson says that immersion in the active world is essential to understanding what other Men Thinking have written about it. The reader who does not bring a base of action to his reading will understand little of what he reads. But, “When the mind is braced by labor and invention, the page of whatever book we read becomes luminous with manifold allusion. Every sentence is doubly significant and the sense of our author is as broad as the world.”

If readers not “braced by labor and invention” get little out of what they read, writers not braced by labor and invention can put little into what they write. As Emerson says, action is essential. Without it, thought can never ripen into truth. Readers instantly know whose words are loaded with life, and whose are not. “I learn immediately from any speaker how much he has already lived, through the poverty or the splendor of his speech. Life lies behind us as the quarry from whence we get tiles and copestones for the masonry of today…. Colleges and books only copy the language which the field and the work-yard made.”

Missing the Boat

Thinkers who cannot write authentically have what I call the James Fenimore Cooper syndrome. Cooper was an early American writer who was fascinated by the American Indians and wrote several stories about them including The Deerslayer and The Last of the Mohicans. Cooper’s writing was later skewered by the great American humorist Mark Twain as being hopelessly inaccurate fantasy (“Fenimore Cooper’s Literary Offenses” [1895] in How to Tell a Story and Other Essays, Oxford University Press, 1996).

In a scene from The Deerslayer, Cooper has six Indians climb onto a sapling overhanging a river to wait for a scow being hauled upstream by rope. The Indians’ plan is to jump onto the roof of a cabin on the scow which is 90 feet long and 16 feet wide in the middle of the scow. The six Indians precisely time their jumps onto the cabin roof, but one falls short of the roof and lands on the boat’s stern; the remaining five miss the boat entirely and land in the water.

Twain had been a riverboat pilot, and he took Cooper to task for his sloppy description of a subject Twain knew intimately. Twain pointed out the implausibility of a “sapling” being able to support the weight of six adult men. He then pointed out that according to Cooper’s description of the river, a scow one-third the length of Cooper’s scow would have had difficulty navigating the twists and turns in the river; Cooper’s scow would have wedged itself into a corner halfway through the first turn. As for the Indians’ jumping, the maximum speed the scow could be pulled upstream was about 1 mile per hour, which would have given the Indians a minute and a half to jump onto the boat, and a full minute to jump onto the roof of the cabin. That amount of time hardly calls for precise timing, but Cooper’s Indians managed to miss the cabin anyway. Perhaps they lost their concentration when they realized that Cooper’s river was only two feet wider than Cooper’s boat at the point it passed the Indians’ location; they could have saved themselves some trouble by simply stepping onto the boat from the shore as it scraped past them, but, as Twain says, Cooper didn’t allow his Indians to hop on from the shore, and their mishap is his fault, not theirs.

At the 17th International Conference on Software Engineering, David Parnas pointed out that the papers from earlier conferences that had received awards for being “most influential” had arguably not been influential at all (“On ICSE’s “Most Influential” Papers, Software Engineering Notes, July 1995). I think the James Fenimore Cooper syndrome is part of the reason. These papers might influence researchers, but they do not influence practitioners because, to practitioners, the methodologies they describe seem about as authentic as Cooper’s Indians.

Authenticity

Practicing software developers are every bit as skeptical about software development handbooks as Twain was of Cooper’s prose. Software methodology books are seen as theoretical, applicable only to small projects, hard to adapt, inefficient, and incomplete. Software authors sometimes bemoan the fact that the average software developer buys less than one software development book a year, but I do not think the reason for that is such a great mystery. Developers will buy books that have been “braced by labor and invention,” but not books that, like Cooper’s Indians, miss the boat.

Mark Twain argued that the best frontier adventure stories were written by people with keen eyes for detail who had actually lived on the frontier, and I am convinced that the best software handbooks will be based on the work of software developers who have recently lived through production software projects. To apply Emerson’s point to software engineering, the tiles and copestones of software engineering handbooks must come from The Programmer Writing, from people who are actively participating on production software projects and who occasionally take time to reflect on their work and write about it.

A Call to Action

If you are actively developing software, I urge you to write about your insights. If you have worked on a project that taught you valuable lessons, share them—whether they are coding details, quality assurance practices, more effective project management, or even a software development topic that doesn’t have a name yet. Submit your writing to IEEE Software or some other magazine, or fully develop your ideas into a book. If your insights are stronger than your writing, find a consultant, seminar instructor, university professor, or other skilled writer to be your co-author. You don’t need to worry that what you have learned won’t apply to other people’s projects. As Emerson says, “Success treads on every right step. For the instinct is sure, that prompts him to tell his brother what he thinks. He then learns that in going down into the secrets of his own mind he has descended into the secrets of all minds…. The deeper he dives into his privatest secretest presentiment, to his wonder he finds this is the most acceptable, most public, and universally true.”

Editor: Steve McConnell, Construx Software  |  More articles