APRIL 2006 (Vol. 39, No. 4) pp. 100, 98-99
0018-9162/06/$31.00 © 2006 IEEE
Published by the IEEE Computer Society
Published by the IEEE Computer Society
In Praise of Professional Precision
PDFs Require Adobe Acrobat
In professionalism as in programming, prescriptivity, particularity, perspicuity, and profundity should be paramount.
In a letter published in Computer's December 2005 issue, Michael Hobbs took me to task for seeming "to prefer structure and organized taxonomies" (Letters, p. 5). He noted that I advocate "that we need more precise, prescriptive definitions for our technical terms." By contrast, Hobbs described himself as "more of a laissez-faire kind of guy—let a thousand flowers bloom, and so forth."
Actually, he didn't take me to task for pedantry but for the inconsistency he saw in an earlier essay, an inconsistency that my published response addressed. Nonetheless, Hobbs touched on a particularly pertinent point, one I feel must be strongly pressed, as this column's regular readers will have realized.
Letting a thousand flowers bloom is just fine for a florist, but a botanist, as a member of the professional arm of floristry, must be precise about just what plants those flowers are blooming on. In the same way, we have a duty as computing professionals to be precise in our technical writings and discussions.
Precision in language has many aspects. To be precise means, according to The Oxford English Dictionary, to be "Strict in the observance of rules, form, or usage; formal, correct; punctilious, scrupulous, particular." These definitions overlap somewhat, so we will here distinguish between prescriptivity, observance of formal rules; particularity, attention to details of correct form; perspicuity, punctilio as to clarity and lucidity; and profundity, scrupulousness in making fine distinctions.
Precision in professional language has two purposes: to make communication with fellow professionals specific and unambiguous, and to inform people outside the profession meaningfully and clearly. Of course, all serious communication should be meaningful and clear, but with fellow professionals it's also necessary to use a modicum of jargon and initialisms that will be neither meaningful nor clear to others.
Rules are the basis for conformity, which is the precept for preventing confusion and disagreement. Computing professionals are quite comfortable with observing formal rules when coding programs for compilers, but observe formal rules rather passively when putting other text together.
There are two kinds of formal rules to be considered here. The first is professional, the second pervasive. Professional formality is embodied in formal standards, such as the IFIP-ICC Vocabulary of Information Processing ( www.iso.ch/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=7229), a vocabulary that supposedly has some legal status. This vocabulary of basic terms is all but unknown within the computing profession, an ignorance reflected even in the conflicting and inconsistent definitions given in popular computing dictionaries.
I reviewed professional aspects of this vocabulary in "The Great Term Robbery" ( Computer, May 2001, pp. 96, 94–95), making public the professional shame of abandoning the standard definitions of the two most fundamental terms of our profession: data and information. The standard definitions contrast people and machines: machines only process data while only people process information.
Other international standards also must be more widely propagated. Perhaps the most important to be persistently maltreated by the public and the professions is the system of prefixes for units of measure, particularly the table of symbols in which, for example, m stands for a thousandth, M for a million, and G for a billion ( www.bipm.fr/en/si/prefixes.html). Yet technical professionals of all persuasions make no protest when the popular press uses m for a million and bn for a billion.
However, it needs to be said that these prefixes don't deserve respect. Using μ for a millionth is puerile, and the full prefixes are puzzling, sounding more like an extended Marx Brotherhood than a practical paradigm. Much more potent would be suffixed scaling of the kind used in programming, where 1k2, 2k3, 1m2, and 2m3 would stand for a million, two billion, a millionth, and two billionths, respectively. The computing profession could promote such scaling by supporting it in all coding schemes and calculators as a preliminary to pushing for it as a general standard, coupled with the phasing out of at least the more bizarre prefixes.
Pervasive formal rules are rare in the English language, whose dictionaries are descriptive rather than prescriptive, although they do posit correct spelling. Various publishers use style guides to promote uniformity in grammar, expression, punctuation, and format. The IEEE Computer Society uses The Chicago Manual of Style (Chicago University Press, 15th ed., 2003), although additional guidance can be found in the Author Resources section of its Web site.
Even so, the prescriptions of style guides have enough in common in some areas that they should be regarded as formal rules. Apostrophes provide a prime example. They mark omission ( can't) and possession ( today's) but never directly mark plurality; thus for the plurals: 1990s not 1990's, sixes not 6's, ells not l's, and CPUs not CPU's.
Principle: Obey the rules.
Where no formal rules exist, precedents can still be found, with the two schools of thought being the permissive and the prudent.
In the early days of Datamation magazine, Truly Donovan wrote that "in English there isn't a noun that can't be verbed" ( http://trulydonovan.com/wordworks/ignorable.htm). This pert and memorable pseudoproverb promotes personality rather than communication. Just because the rules permit verbing a noun doesn't mean it's prudent to do so. In professional reporting, the facts should be novel, not how they are worded, and this is done by respecting tradition.
An important reason for preserving tradition in professional prose is to make the meaning clearer for people without a technical background and for people whose native language isn't English. An example here is the recent popularity of input and output as verbs, even though ordinary people never input their cat or output their lights. One joy of traditional English is how meanings can be built upon verbs like put; we put papers aside, put parties off, put up with pedants, put parcels away, and so on. Such patterns should be preserved.
Some traditions have an expressive advantage. Words from Latin like agenda, corrigenda, data, and memoranda are traditionally plural, but agenda has become singular, which leads to the clumsy agenda item rather than agendum. Data is sadly going the same way, with Google giving "data is" twice as many hits as "data are." This trend should be resisted, if only to save us from data item and item of data.
Principle: Respect tradition.
Beyond formal rules and respected traditions, there are practices, simplification in particular, that will clarify technical prose. Splitting long sentences will often let conjunctions be left out and make an argument easier to follow. In technical writing, long arguments will often become clearer and shorter if they are formatted in lists, particularly if text common to each point can be put once in a prefix—items in a list needn't be complete sentences.
Many commonly used phrases can be shortened. In software programming the software is redundant. The same treatment can be applied to forward planning, ballistic missile, and multiple examples. A software entity is just a program. Preventive maintenance is preferable to the preventative variety, and indeed if there is a distinction to be made, it should be between maintenance and repair. The word environment can usually be left out of phrases like host environment and network environment, and process can be left out of creation process and loading process.
Pretentious words can be replaced by ordinary ones. The terms use, run, leave, and first can usually replace access, execute, exit, and initial, for example. And—a personal peeve—I would present to Procrustes the person who first perverted visualize and visualization to mean depict and depiction.
The purpose of such simplifications is to get rid of the kind of jargon that computer users so often encounter and complain about ( http://news.bbc.co.uk/1/low/technology/4272382.stm). Jargon conceals meaning. This was brought home to me once by a response from an operating system maintenance team to which I had forwarded a user's request. Their letter stated that the request was "currently being subjected to scrutinization," a statement that renouned a verbed noun. Although they could tell management this wasn't a negative response, it suggested to me they were going to ignore the request, which they did.
In the more technical writing intended for fellow professionals, meanings run deeper. Simplicity comes from abbreviation, clarity from careful use of vocabulary.
In computing, abbreviation is achieved through initialisms and acronyms ( http://en.wikipedia.org/wiki/Acronym_and_initialism). These usually long phrasal names can be made much shorter by using only the first letter of each word and, unless the abbreviation is familiar, it's usual to introduce the name in full the first time it occurs, then use the abbreviation from there on. An initialism like IBM is an abbreviation spoken as a sequence of letters. An acronym like ENIAC is an abbreviation pronounced as it is spelled. But unless such abbreviations are parsimoniously used, they will only perplex.
In professional writing, clarity comes from paying attention to the meaning of ordinary words used technically and being aware of technical words used by other professionals. Using ordinary words precisely will save lengthy explanations, while using technical words properly will make meaning clearer to professionals unfamiliar with the area being described.
Computing often uses sorting instead of ordering, but these are distinct processes. Comparisons are said to work out which of two comparands is the greater or lesser, but they actually find which is higher or lower, a quite distinct result. Computing professionals "know" what is meant, but interested ordinary readers, or members of other professions, might be confused or simply regard the computing profession as uneducated.
One result of allowing degradation in meaning is that simple ideas must then be awkwardly expressed. Given that unique now simply means unusual, there is no easy way to describe something as being like nothing else at all. Since infinite now means only huge, there is no simple way to say that something is strictly unlimited. When there are no simple words for simple ideas, those ideas become difficult to teach.
Some distinctions between words are quite technical. In computing, for example, accuracy must be contrasted with precision so that users can understand that a precise result is not necessarily accurate, and random must be contrasted with pseudorandom so that users can understand that a pseudorandom number can be predicted while a truly random number cannot. In my experience, many computing professionals do not understand either of these important distinctions.
When professionals fail to carefully preserve basic technical distinctions, the public becomes confused. During the question time after a public lecture on astronomy that I attended recently, it became clear that several people didn't understand that pictures are transmitted across space from the Hubble telescope much as they are from local television transmitters—they assumed television signals arrived via airwaves. When I got home, I found that my Macquarie Dictionary defined airwaves as "the medium used for transmission of television and radio signals," although it did parenthetically note that this was a "nontechnical" definition. Even so?
Principle: Make distinctions.
What is permissible in poetry and fiction will often only confuse and mislead when used in factual reporting. When writing reports and other professional text, there are four principles to be pursued: obey official rules, respect tradition, simplify, and make distinctions.
Neville Holmes is an honorary research associate at the University of Tasmania's School of Computing. Contact him at firstname.lastname@example.org. Details of citations in this essay, and links to further material, are at www.comp.utas.edu.au/users/nholmes/prfsn.