Bad Language (I)

 

Software projects are famously awash with gibberish. Take a glance at the last few emails in your inbox. Few would make any sense to a layman without hours and hours of background and explanation. You might be clear as to what constitutes a barrier to release but come at it cold when accustomed to normal everyday mumbo-jumbo-free English and it’s at best opaque. Something to do with rehabilitating criminals ? Returning zoo animals to the jungle, maybe ?

There are many root causes behind this and at least one is legitimate. Computing, like every other area of human endeavour, has inevitably developed its own lingo to handle concepts peculiar to itself. Scopecreep, bytecode, API, and regression would mean nothing to your entirely literate and intelligent mother, but have handy and well understood definitions to us. Avoiding terms like these is silly; you could if you wished refer to the very last phase of testing as “end user checking to ensure that the software has been written as expected, conforms to specification and is suitable for the purpose intended” but there is every reason to save yourself time and puff by saying instead “UAT”. Jargon used as a short cut to explanation is eminently sane and the alternative turns sentences into paragraphs and brief emails into long Victorian novels.

Less usefully, there is the habit of taking a simple state of affairs and rendering it obscure and impenetrable. This is as endemic in our trade as social awkwardness, poor personal hygiene and an ability to take Science Fiction programmes on the telly far too seriously. It’s perhaps acceptable when someone is compelled to mask an inconvenient truth or waffle around an embarrassing cock-up, especially if those listening include the top brass that created the conditions that led to it in the first place. I have heard each of the following lines delivered more or less straight-faced to such a group:

  •  “The programme of activity as outlined is a roadmap indicating intent, rather than a fully-fledged, baselined plan of record.” Nobody has the faintest idea what we are meant to be doing, or when.
  • “The resources ringfenced for the project are not ideally correlated with the required skill set.” All the decent engineers were taken. I got the morons.
  • “The delivery is to be de-risked by streamlining scope and focussing effort toward the low-hanging fruit.” There isn’t any time left so we’re just doing the easy bits.

The last is my favourite, from a sly tactician of my acquaintance. It slips down so easily, like ice cream. What cretin would argue against streamlining and focus, or in favour of adding risk ?

It’s possible to excuse this type of rhubarb when the speaker has been put in a tight spot and is wiggling out. But without extenuating circumstances, it’s rotten, unforgivable, and these days, surprisingly convoluted. Modern day business technology nonsense is multi-layered. Symphonic, even. The tune, if you will, is carried by the buzzwords we know and love. Beneath that is the more complex polyphony of twaddle, where common or garden words are twisted out of shape and sentences warp under the weight of misconception, spin, disingenuousness, high-gloss idiocy and outright fibbing. Let me pick out some of the more common melodic lines.

Vintage Buzzwords, Two-For-One offer. Blue Sky to think in and a Flagpole to run some ideas up

Vintage Buzzwords, Two-For-One offer. Blue Sky to think in and a Flagpole to run some ideas up

 

 

 

 

 

 

 

 

  • Buzzwords and buzzphrases are essential, but you must keep up to date. Blue Sky Thinking and Running Ideas Up The Flagpole are so last century. Ideation, Envisioning and Transparency have a bit of steam left, and I still hear Synergies being Leveraged without a hint of irony. Having mastered the current vocabulary, extend it. Verticals and Horizontals are all very well, but you need to get cracking along a few Parallel Diagonals too.
  • Myself and Yourself. Always. Never me or you. In general, don’t use a short word where a long one (ideally, four or five long ones) will do. Dialogue instead of talk. Execute instead of do. Sub-optimal instead of crap. “Initial review indicates a substantial number of shortfalls across the piece which need to be addressed by yourself directly within an immediate timeframe” rather than “I ran your code. It’s broken. Fix it now.”
  • The passive voice is always to be used. Actions have been taken and mistakes may have been made, but it is not at all clear who did what and with which and to whom. No names, no pack-drill, no attribution.
  • Strategic. Strategic is good. Business-wide is good. Spanning the Enterprise Space is fantastic. Anything that sounds BIG and EXPENSIVE is good, pretty much without reservation. IT leaders imagine that what they are building is vastly important, all-encompassing and will endure for many, many years. They would have you believe that what will emerge from their Grand Vision is the software equivalent of the Channel Tunnel or Heathrow Airport. Never mind that a Strategic Technology Direction usually lasts about as long as an X-Factor winner’s career, or that the oft-derided but functional old system will still be live after seven different generations of Global Reference Architecture have died.
  • Tactical. Tactical is bad. So is Niche, Legacy, Bespoke, Stop-Gap and Temporary. Anything described in those terms is being slagged off. You might think that being designed for and fulfilling a specific need is a good thing but in the world of IT Shambles it smacks of lack of ambition. You might not have bitten off more than you can chew.
  • Words without Meaning. As with Tactical and Strategic, there are many terms which convey nothing except to suggest in the vaguest way whether something is thought to be any good. They may have started as perfectly serviceable pieces of English but any practical purpose and meaning has long since been ground out of them. Years of poor and excessive use in Powerpoint slide packs and doorstopper-thick proposal documents has squeezed out all of their juice. Capability, Drive, Initiative, Discipline and Quality are all on the Good list, whereas Naive, Exposed, Shortfall, Understand and Help are all on the Naughty List. For example:

Good: “A new initiative is to be rolled out during next quarter to build on capabilities within the Engineering discipline. Robustness of delivery will be driven up still further within the context of continuous improvement to achieve superlative quality.”

Naughty: “The naive, piecemeal approach taken to staff development and succession planning in the past has left the department dangerously exposed. It has become essential to engage external resource in order to help Engineering understand and alleviate longstanding but avoidable shortfalls in core knowledge areas.”

Both quotes mean “The developers are going on an Oracle training course.” but in the second case it’s because they’re idiots.

Understand and Help you may baulk at, but they always set off red lights and a klaxon in my head. Seriously, if any fluent tripemonger ever tells you they want to Understand your problem and Help you with it, run like bloody hell. Or whack them in the face with a rusty shovel.

  • Clumsy military, sporting or industrial metaphors used in order to impart the sweaty tang of brawny masculinity to what is in fact a rather fussy, sedentary, even effete, office job. Often mixed to disturbing effect e.g. “The team’s bunkered right down, hacking away at the coal face and taking a gut full of flak for their pains but still sticking the ball in the back of the net time after time.” So they’re flying a bomber under fire through a trench. As they dig out a seam of nutty slack dahn t’pit, and play footie.
  • We’re All In This Together. Everything must ostensibly be collaborative, shared and faux-chummy, to the point of acute physically discomfiting embarrassment. It’s not the Leadership Team’s Achievement – it’s Everyone’s Achievement. You should be Proud. Take a moment out to Congratulate Yourselves. We’ll put some time in the diary in Q2 to Celebrate Success and Down a Coupla Beers with y’all. Great. Super. But I want to Share with you some of the Challenges still facing Us All. These are not the Board’s Deadlines – this is Your Plan. You Signed Up To It and You Own It. Yeah, just like I own the house when there’s a six-figure mortgage on it. I would far rather have a 1950s-style boss in a brown tweed suit who never celebrates success, but does tell me what to do straightforwardly and firmly. If the company is transforming itself into a People’s Democratic anarchist collective, then great. I’ll grow a beard and rustle up the mung-bean curry. If not, let us be honest and admit that we are a standard issue, top-down, command-and-control-type operation. Let us not be ashamed of that, or pretend to be otherwise.
  • Brainless, Relentless Positivity. One finds oneself continually exhorted to Make It Happen, Get On The Bus, Embrace The Values, Drive Toward Success or whichever flavour of Just Go For It ! your employer favours. And of course, we are always Going Forward. Several times per corporate communication cascade email, normally. It is like being trapped in an ‘80s aerobic workout video with dashes of ‘30s Soviet propaganda film thrown in. This starts with the passably laudable aim of geeing up the workforce, and ends by roping in all sorts of inappropriately hyperbolic abstract nouns. Passion. Joy. Spirit. Cool. Miles Davis was Cool. Johnny Depp is Cool. Computer programming is not, and me, I’ll reserve Passion, Joy and Spirit for when I get lucky on a Saturday night.
  • Shape Up Or Ship Out. Anyone Can Be A Cynic. Get With The Programme. Whatever the programme is, even if it’s deranged. As Relentless Brainless Positivity is compulsory, so doubt, uncertainty and criticism are forbidden, no matter how well founded. Any tricky questions can quickly be ruled out of court as sabotage and obstructionism. The Forward March of the Reengineering Programme Shall Not be Derailed by Naysayers, Sniping From The Sidelines. [Note again clumsy mixed military metaphors: we’re marching, but we’re also on rails, and being shot at.]
  • Should and Ought. Dangerous words. It should be easy. It ought to work first time. It should be much quicker next time. We ought to have learned from our mistakes. Each time a wildly optimistic aspiration is alchemically transformed into a hard fact and “should” becomes “will”, at least in a few minds. But it never quite pans out that way. Just as deadly in private life. We ought to be able to redecorate the bedrooms in a few weeks. The children should help out. Putting in new doors ought to be a breeze. It should be easy to replaster those walls. We ought to be able to spend two or three hours on it most evenings. And then your upstairs turns into a building-site-cum-refugee-camp strewn with toys, clothes and cardboard boxes, and stays that way for three years.
  • Issues, Risks, Challenges, Concerns. These four are overused ridiculously throughout the IT and Project Management racket, rarely sensibly, and have become tarnished by that overuse. In general, they are used to indicate in an indefinite, tangential but pompous manner that something has gone wrong, is about to go wrong or might go wrong, whilst simultaneously shifting the blame from culprit to victim. Issue and Risk pose a particular (ahem) challenge to the gag reflex because of the gargantuan levels of bilge surrounding Issue and Risk Management, as if these were newly discovered branches of natural science. Taking some examples from the extensive literature:

“Acknowledging first that there have been issues recorded relating to the quality of some deliverables received from our outsource partners in Ulan Bator, it is arguable that these are substantively in the realm of design and knowledge transfer at the Uttoxeter end rather than technical competence per se.” They may not be able to write code for toffee, but most of the Directors have shares in them. There’s no way any balls up is going to be pinned on them rather than you lot.

“Quality expectations around the requirement piece are felt to be over-prescriptive, and if allowed to stand, do pose a quantifiable risk to on-plan project initiation.” We don’t know what we’re asking for but we still want you to start building it now.

“The challenge for our technology practice in the coming year is to step up, hit the rising bar and deliver the blueprinted roadmap” We know you’re all backsliding dimwits, we know this is impossible, but if you don’t do the whole bloody lot by December, you’re sacked.

“It is not helpful at this juncture to consider the past. Regardless of the history up to this point, serious concerns have now been raised that the system as developed will not be fit for purpose with respect to our customer base.” We signed off the spec. We said it was all great at the walkthroughs and demos. We even approved it all at the end of UAT. But we just don’t like it now. Dunno why. It’s just grotty. Nasty. Boring. Have you seen my iPad ? Now that’s really nice. Can you make it more like that and Facebook ?

  • Resource. In standard English, resource means iron ore, Brent Crude, soya beans – commodity products, where one container-load leaving Felixstowe docks is absolutely the same as another. In balderdash-ese, “resource” means “worker”, but retains the dim and awful connotation that one little person is just the same as any other little person. Which they are, viewed from the lofty eyrie of Senior Management, somewhere near the top of Mount Olympus. The Little People. Our Minions. Interchangeable. Like Pork Bellies.
Bauxite. Natural Gas. Developers. Pork bellies. It’s all Resource.

Bauxite. Natural Gas. Developers. Pork bellies. It’s all Resource.

So we have established that there’s gallons of double dutch swilling around IT. Almost everything written and most that is said is soaked in it. This in itself creates more, through the multiplying effect of peer pressure. Obfuscatory gobbledygook has for decades now been the lingua franca of our world. Even if your natural mode of expression is single syllable grunts, you have to churn out polysyllabic bullshit in order to be taken seriously by everyone else. And so, powered by social conformity, we all help to perpetuate a self-sustaining chain reaction of circumlocutory tosh.

In earlier years, you may well have arrived at infant school speaking nice, polite BBC English like your parents. If so, you will have found out early from the hard kids that there was a whole swathe of bad language you never ever heard from Mum, Dad or The Archers. In order to avoid sticking out like Kristin Scott Thomas in the Burnley branch of Primark, you had to learn pretty quickly how to eff and blind like the big lads. Fluency in verbose managerial baloney is the adult equivalent of learning to swear. It’s expected, and you’ll be laughed out of the envisioning workshop if you ever call a spade anything less than an operative-powered manually-directed entrenchment solution. Could be worse. Go back to age four, and you’d get debagged, wedged and bog-washed as well.

Below: Kristin Scott-Thomas.  Primark, Burnley. Spot the difference.

K S-T

K S-T

Primark

Primark

Burnley

Burnley


Advertisements
This entry was posted in Uncategorized and tagged , , , , , , , . Bookmark the permalink.

4 Responses to Bad Language (I)

  1. Pingback: Bad Language (II) | IT Shambles

  2. In one of my jobs, there was a requirement document that used “MoSCoW”: Must, Should, Could, Would. Requirements had to use one of these words. So “the application must allow the user to specify different login credentials,” “the report should …” What’s the difference, someone might ask. Well, the difference is that Must comes before Should, comes before Could comes before Would. The last one doesn’t even make sense (“the application would…”? If it only could, it surely would). So we always ended up ignoring all requirements except the “must”.

  3. itshambles says:

    This is one of those cases when some bright spark came up with what he thought should be a zinger of an acronym and then tried and failed to make it work afterwards. Must comes first, clearly, but for Could, Should and Would there’s not really any obvious order. But as you probably experienced, 97% of all the requirements turn out to be Must-Haves and the users are incapable of prioritising between them in any case so it’s all for naught.

  4. Pingback: The Extended Dream Team (IV): Core Incompetencies | IT Shambles

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s