Alas, I am that most unsatisfied of creatures, a pedantic
descriptivist. I am annoyed by awkward constructions but lack the
consolation of labeling them as wrong.
But then I do employ casual constructions and idiomatic expressions in
my writing (and speech) - often even in formal writing, when
appropriate for reasons of style. I was merely agreeing with John's
impulse to correct the agreement in number in his first post.
I've been trying for years to hit the right balance in blog articles,
design documents, RFP responses, presentations, tutorials, teaching
handouts, Usenet posts and Web forum questions, and also my own writing
for pleasure (this latter itself being of many different types). All I
know for sure is that I dislike (in varying degrees) the following:
1) _excessive_ use of elaborate or unusual words: I don't believe, like
many seem to do, that every use (utilisation) of big words is an
affectation (puttin' on airs) or replaceable with a smaller, easier
word. Many of these big words actually have subtle, enhanced meanings
that their simple proposed substitutes don't. But the prerequisites for
using big words include understanding the exact meanings, knowing that
the simple word is not a close-enough substitute, and remembering to
write for the audience.
There are few things worse than an unrelenting barrage of complex,
Latin-based verbiage.
2) incorrect spelling, _particularly_ when it's obvious that it's not a
typo. Examples: "she poured over her material", "that was a breech of
security", and "the shed wreaked of gasoline". I blame lack of reading
for this problem; it's not possible to make these mistakes (or for that
matter, to be a bad speller, period) if you read voraciously.
3) writing without a plan: a disorganized and tenuous grasp of facts and
conclusions in one's head translates to an equivalent mess on paper. The
act of writing does not improve the material.
4) using language as a nefarious tool: this technique often makes use of
my first point. It also employs skillful tense and pronoun and adjective
selections to divert and diffuse responsibility, or to disguise a lack
of real content.
There is no shortage of software consultancies that do exactly this, and
it gets really horrendous when the clients are government departments.
I'll produce one common example - a notional consultancy is called upon
to produce a software design document. You and I, being software
developers, would like to think that technical people are the audience
for such a document, and that technical people pronounce on the
acceptability of the finished version. Such is rarely the case - the
authoring consultancy produces beautiful but vapid high-level bumwipe
that is presented to the PMs and higher, and approved by higher client
management. Little matter that it's a useless design document devoid of
concrete information that would help implementors.
Even better, when the project fails, weasel-English can now be used to
blame the _implementors_. The typical design doc I've seen parrots the
*business* requirements (few clients know what technical requirements
are) and pads out the design with some pretty but fairly useless UML.
But all the PMs and client managers understood and liked this design doc
- still do - and they _approved_ it, so clearly the coders must be at
fault. It's the _coders_ that don't get the design doc. Right?
In fact there's nothing there to get, but the bosses don't want to hear
that.
I had the pleasure some months back of being commissioned to do 20 days
worth of work writing up a detailed design document in such an
environment. Normally for this client I do maintenance rescue coding,
but in this case the problem was complex and actually required a
developer - not a BA - to do the design. At the end of the 20 days I had
not only a clear and concise *real* detailed design document - one that
another developer could use - but also a working POC of the
solution...which hadn't even been expected by the client. It hadn't been
expected mainly because the other software consultancies are loaded with
PMs, BAs and mediocre coders, so the clients aren't used to adequate
performance.
The best measure of this detailed design document that I produced is
that, in marked contrast to the usual design docs that floated around
that office, the higher up the food chain you went with it, the less
people were able to understand it. Any other coder, excellent grasp of
what I wrote. An architect, not so good, because a lot of architects are
not good coders (in my experience). PMs and mid-level managers, serious
struggling. High-level managers and directors, hang it up - you read the
executive summary I prepared.
The point being, I've found that obfuscatory English is used as a weapon
to disguise incompetence and inefficiencies, or worse. I've seen some
pretty horrible wastage of taxpayer money precisely because muddy and
weaselly English let all the players wriggle out of accountability, and
often enough even get rewarded for their previous disaster.
So that's why I like clear English.
AHS
