“Read not to contradict and
confute, nor to believe and take for granted, nor to
find talk and discourse, but to weigh and consider.”
— Francis Bacon
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.”[1]
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.[2]
Who should write these handbooks?
In August 1837, Ralph Waldo Emerson
delivered an address that came to be known as “The American
Scholar.” One hundred and sixty-five years later, I believe it
contains the answer to the question of who should write these
software handbooks.
As the software book publishing industry is
currently configured, most software development books are
written by six kinds of authors:
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 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 Labs, and similar environments
have produced some of 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 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.”
I call thinkers not being able to write
authentically 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.[3]
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 that 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 one 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.[4]
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.
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 are 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.
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 a
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.”
[1] Brooks, Fred, “No Silver
Bullets—Essence and Accidents of Software Engineering,”
Computer, April 1987.
[2] “Scaling Up: A Research Agenda for
Software Engineering,” Communications of the ACM,
March 1990.
[3] Twain, Mark, “Fenimore Cooper’s
Literary Offenses,” 1895.
[4] Parnas, David, “On ICSE’s “Most
Influential” Papers, Software Engineering Notes,
July 1995.
This
material is (c) 2004 by Steven
C. McConnell. All Rights Reserved. |