As an avid reader of Robert Glass's columns, I was astonished to see him admonishing the purity of form required by an academic technical paper ("Stodgy by Design and the Notion of 'Dumbing Up', Feb. 2002).
Just kidding.
Glass touched a nerve, mostly because I believe clarity of communication, not form, is one of the most important issues in computers today.
Glass calls professional writing stodgy. Well, I'm arrogant enough to call it what it is: bad writing. I love Glass's writing style; his columns are the first I turn to when Communications arrives in my mailbox. They convey concepts quickly and with lasting impact.
I remember my first professional conference. One of the things that made an enormous impact on me was the nearly completely stifled prose, so wrapped in jargon and formalism that I could barely understand what was going on. It took me years to realize what I was experiencing was not, as I suspected, a lack of understanding on my part, but was, in fact, poor communication.
If you can't say it and get out, then don't say it.
There's a certain amount of "playing the game" when it comes to professional writing, but I also believe there is an element of enshrouding our work in an aura of mystery and complexity that is completely unnecessary.
I was once on a standards committee, and made an attempt to simplify the layout and prose of a document the committee was working on. I was informed by one of the committee members that this document was "not meant to be understood by the layperson" and was a discipline requiring "extensive study to understand." I pointed out that in practice, extremely intelligent experts had problems understanding it. I think it just made the person more smug.
The infuriating part of the experience was that the murkiness of the standard had little to do with inherent complexity and everything to do with poor communication. I just wish I could turn my high school journalism teacher loose on those guys for a few hours. They probably wouldn't make it out alive.
Organizations and their projects grind to a halt when communication becomes overburdened with formality. Requirements fail to be understood, resulting in delays or cancellations of projects. Code suffers when people fail to realize their code is not an exercise in how much one knows, but an exercise in how well one communicates its purpose and structure to the next person who will crawl through it. User interface suffers terribly when simplicity and clarity of purpose are left behind.
I believe the core of good software development practice is good communication, both written and verbal. This does not mean using the latest and greatest notation and jargon; it means getting your ideas across to your peers. It is not their duty to work through what you are telling them, it is your duty to get the knowledge across to them in the simplest fashion possible. The goal is not to be mysterious and all-knowing, the goal is to share.
But now I'm just starting to rant when all I really mean to say is:
Pete Magsig
Ann Arbor, MI
While I sympathize with Glass's efforts to liven up professional writing, there is a point he overlooked: international readership.
Many Communications readers are not native English speakers, or are native speakers but not educated in the U.S., and will not understand American colloquialisms. I am speaking from experience; I work in Europe.
Reviewers tend to have narrow notions of what constitutes good writing. A paper I once co-authored with a British researcher came back from reviewers with a suggestion to have the paper "revised by a native English speaker before resubmitting," because we used the word "whilst" and the passive voice, which are considered perfectly normal on my side of the Atlantic.
Marc Shapiro
Cambridge, England
Glass touched a nerve for me (again) with his column about the formality of scientific writing. Forty years ago I had a boss, a chemist, who had exactly the same gripe Glass put forward in his column. I agreed with him, but didn't think much about it at the time. Over the intervening years, though, I've learned a few things about human behavior and about the behavior of scientists and the difference between the two.
The stylistic issues Glass raised reflect a deeper bias in 19th and 20th century science: the belief that (to exaggerate only slightly) if it's human it cannot be science, and if it's science, it cannot be human. One of the most unfortunate results of this belief is that it makes the term "behavioral science" an oxymoron.
Glass's language, "What kind of impoverished society tends to stamp out color in its way of speaking?" brought back the words of a leading mathematicians of the early 20th century: "Mathematics is like a room in which everything is painted white." Stamping out color in your way of speaking is a form of stamping out color (or emotion, or feelings, or significance) in your way of living, and this is an occupational hazard of scientists.
The world of science is an impoverished relative to the real world in ways exactly reflected by the differences in language Glass points to. And, especially when scientists speak or write on philosophy or religion or popular topics, that poverty can leak out and infect the rest of us.
What particularly pains me is that this poverty is unnecessary. Science can keep its objectivity, relative freedom from culture, and protection against errors without sterilizing itself of everything human. I'd love to see some change on this score in my lifetime.
Paul Zeiger
Tucson, AZ
I really liked Glass's article on stodgy vs. informal styles of writing. Like Glass, I am firmly in the camp of those who prefer a more informal style of writing.
A formal and fancy style usually gives me a feeling that the content is lacking in some way. Puffy language often seems an attempt to make ideas either more important than they are, or to hide a lack of intellectual rigor and completeness. Lastly, as an author myself, I insist on simple language. If I can't explain ideas in a straightforward way, then I really don't know the topic well enough to write about it.
Thanks again for a great column.
Pete McDougall
British Columbia, Canada
Two points in reply to Glass's column. (1) This attitude exists outside academia. I once wrote a successful radar simulator control program. I then taught the users and, using the things I learned from teaching the users, wrote the users' manual. The only negative comments I received about the manual were not using the passive voice and my use of contractions. These were the same users that had no complaint about the personal instruction they received that was in the passive voice and that used contractions.
(2) Each author has to decide what the purpose is of his or her writing. My belief is that much of the time those who play "that silly game" write to impress others; authors that don't try to communicate facts and ideas that will help practitioners. When reading Communications I can usually tell within a paragraph or two which camp the author is in. Life is too short, and I'm under too much time pressure, to waste time on authors whose goal is to impress instead of help me. I realize my practice of skipping articles that play "that silly game" sometimes results in my missing valuable information. On the other hand, if the authors build communication barriers that seem designed to keep busy practitioners out, I am willing to accommodate them.
Mr. Glass, please don't change your writing style for the "Practical Programmer."
Earl Furman
Ridgecrest, CA
Glass's column reminds me that the culture of bad writing is only hurting itself. It would serve practitioners better to be less impressive and more helpful. Practitioners don't read bad writing, and thus the scholarly journals are not very influential.
There was an issue of the Journal of Computer Documentation a few years ago that discussed rhetorical tone in computer manuals. It compared the Word manual with Word for Dummies, explaining why Dummies books inspire more trust than the Word manual. A conversational writing style has a lot to do with it. Casual writing skills give us an important edge in the battle for the hearts and minds of software people.
James Bach
Front Royal, VA
I enjoy reading the "Practical Programmer." However, I take issue with Glass's "dumbing up" column. One of the basic tenets of building usable systems is to use language and idioms familiar to the end user. The rationale is that the fewer new things the user must learn, the faster and more complete the learning process.
Applying this to Glass's column, formality in language is the idiom of the academic world. If his goal is to have ideas taken seriously when writing for an academic journal, he should use the academic idiom. If his goal is to tweak the tail of the academic establishment, then he should write informally but be prepared to have his ideas ignored. I sense some ambiguity about these goals regarding the paper discussed in his column.
Len Bass
Pittsburgh, PA
Many thanks to Glass on his observations about academic publishing. Tenure seeking, self-inflated reviewers often insist on over-formalized, unnecessarily complex language. Language is meant to communicate. Stodgy writing usually gets in the way of persuading, educating, or arguing one's point of view. Why just take a look at the writings of Donald Knuth. He's a master of communication and education, without the stodgyness. Clear ideas, expressed to the point, with perhaps a touch of humor make for much better reading. Let's stop insisting on playing the stodgy writing game.
Sandy Ressler
North Potomac, MD
I can completely relate to Glass's experience. I've been writing for popular programming magazines for the past five years, and my readers always thank me for making the topics easy to understand. But when I submit a paper to an academic conference, I automatically revert to the artificial language of academia only because I know to do otherwise will hurt the chances of my paper being accepted. Although the conversational writing style I use in my magazine columns may not be the best way to communicate in a research paper, a more casual style than the one I'm forced to use would be more effective.
Daniel Savarese
Columbia, MD
©2002 ACM 0002-0782/02/0600 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2002 ACM, Inc.
No entries found