CODES AND STANDARDS
CODESPEAK, JIBBER-JABBER, GOBBLEDYGOOK AND DOUBLESPEAK

Have you ever tried reading a pressure vessel code as if it was a book?

Here at Matthews Integrity Hub: HEAD OFFICE we decided to try it one day, and see how it went. It wasn’t so much the content that was difficult, it was the way that is was written. We started reading it at about 0900 with the intention of picking out the main requirements on pressure containment design, noting them down and turning them into a basic summary in an hour or so. By 0905, at the end of the first page, we had passed no fewer than 35 cross-references to other parts of the construction standard we were reading and four to other related standards.

One of the difficulties was; we had no way of deciding which, if any, of the cross references were important and which weren’t .Either we were supposed them all, meaning we’d have to spend an hour on page 1, or we ignored them.

On page 2, the list of exceptions started, negating the application of what we’d read in page 1 for various situations; there was even a couple of exceptions to the exceptions, effectively double negatives to add to the mix…we hadn’t found a solid principle to write down yet, and only 900 or so pages to go. We wondered how on earth we’d ended up looking at something like this.

Time for a break. We thought about making a cup of tea and wondered idly what we’d do if the instructions for making tea would look like , expressed in the same way as what we were looking at. Maybe something like this;

Standard rules for preparing hot drinks, not excluding tea and coffee

Contents: Clauses TEA-1 to TEA-564 (257 pages)

TEA-1 Units of measurement

Standard cup-sizes are to be used for all aspects of tea making except where unfeasible or impractical. When tea is made at locations where local custom is to use teapots rather than teabags to make tea then this clause shall not apply, unless a receptacle is being used as a cup or a teapot or a glass owing to local custom, each being treated on a case-by-case basis. Exceptions to this include: hot drinks as described in clause TEA-2 and drinks not classified as hot drinks in clause TEA-3

TEA-2 Terminology

Hot drinks shall be defined as drinks that are not cold drinks, except when they are warm drinks. Exceptions to this are set out under clause TEA-1 and TEA-3. Additional exceptions are set out in tables TEA-123 to TEA-156.These shall only apply to drinks designed for drinking at less than and including 80 degC.

Phew; that was enough for the moment….clearly this wouldn’t make the technique of tea-making very easy to follow. We started thinking about the problems of codes written like this, and what the actual problem is. Eventually we decided that it is various barriers to communication included in documents like this that makes them such impenetrable going

Codes and Standards: Barriers to Communication

When talking about confusing writing it’s important not to get some terms mixed up.

Gobbledygook

Gobbledygook is something used in writing or language that is meaningless or is made unintelligible by excessive use of complicated technical terms. Don’t confuse it with jibber-jabber which refers to rapid talk that is difficult to understand. Most gobbledygook is not jibber-jabber. It is difficult to avoid including a little bit of Gobbledygook when writing technical codes and standards but ,looking through some typical codes, a couple of the better examples we found were:

Collaborative Activity

‘Persons in the manufacturing management structure should collaborate within a process to carry out their organisational objectives. Depending on their genesis, prescriptive activities require and understanding of the objectives of the organization, in comparison to those which are non-deterministic relying on external stimuli to determine their nature and execution’.

Goody, now we know. And how’s about this one?

Project planning

‘A project management plan for a project should incorporate reference to the project quality plan and such other plans relating individually but not necessarily exclusively to risk management, budget schedules, structures, health and safety and other activities as appropriate. The overall plan should recognise that management options in asset management are often arranged as a trilemma between responsibilities to plant operation, maintenance and inspection’

This got our interest; we just had to find out what a trilemma is. It turns out there are two different meanings of trilemma. It either means a choice you have to make from three undesired options, one of which you have to choose, or as a choice among three desired options, only two of which can occur at the same time. Either way it’s difficult to see how you’d use the idea in writing a project plan.

We awarded both of these the coveted status of complete gobbledygook

Doublespeak

Doublespeak is different to gobbledygook. It is defined as language that deliberately obscures, disguises or distorts the meaning of words. We couldn’t think of any reason why this would need to appear in technical codes or standards as it wouldn’t seem to be of any advantage. When we looked a bit deeper however we found that doublespeak can also refer to language that reverses the meaning of words or provides intentional ambiguity .To be fair, doublespeak doesn’t set out to change a truth or requirement but can act to disguise or obscure the nature of it for some reason.

Off we went to hunt for doublespeak. We soon found this little one;

Approved standards

‘For the purposes of this product standard, approved standards for the components covered by the application standard may be followed. Compliance with an approved standard gives a presumption of conformity with the product standard. Alternatively if approved standards are not followed the duty holder may demonstrate that the methods used may either; comply with or exceed the requirements of the approved standard, or alternatively can be shown to be safe’

The doublespeakability of this is a classic. It seems to say that you are meant to comply with approved standards (presumably listed somewhere) but if you don’t then it doesn’t matter as long as things can be declared as safe. The bit in (rather thin) disguise is that compliance with approved standards is not mandatory, if you believe you have another way of doing things. It’s not the world’s worst doublespeak but it meets the definition.

Having paid attention to mistress during school English lessons (Cheltenham actually),we thought some doublespeak terms we found could possibly be classified as oxymorons, a term meaning that the words themselves are contradictory. One we found used in multiple technical codes was:

‘The code neither requires nor prohibits’

This pops up in all manner of technical requirements such as construction, materials, physical design features of equipment weld configurations, types of fittings and similar. Here’s how it manifests itself in plainer language:

Q. Is it acceptable to the code to use either a threaded or brazed fitting in this application instead of a welded one?

A. We’re not saying you can and not saying you can’t, so you can do what you want

Q. What happens is I do use a threaded fitting and it fails?

A. Well it’s your fault because we didn’t say you could use it

Q. What happens if I use a welded fitting and it fails?

A. That’s your fault; you could have used a threaded or a brazed one; they’re not prohibited by the code.

You can argue all night as to whether this is oxymoron-ism in practice or not. It all hangs on whether you believe that two opposing statements can be true at the same time or whether if one is true the other must be false. Either way, statements like that above may not exactly fill you with confidence.

Next Up… Glomar denials

We think we might know where statements like ‘neither require nor prohibit’ come from. They pop up whenever the code committee has not got round to considering fully whatever feature is in question, so they have no idea what to say about it. Instead of just pretending it doesn’t exist they mention it in the way discussed leaving it open. Another common manifestation of this is when codes mention components under the banner of ‘unlisted items’, just another way of saying that they aren’t sure what to say about them.

There’s nothing new about this approach. It is linked to the term Glomar denial. This refers to a response to a request for information that will ‘neither confirm nor deny’ (NCND) the existence of the information sought. Armed with this knowledge you can start to spot NCND statements hidden in less obvious places in technical codes. They don’t do much particular damage, but aren’t much use either if it’s clear guidance you are looking for.

 Gobbledygook Manifesto: The Rule and exception format

We’re not sure what grammatical construct this should be called. It’s the format used in some codes of stating a short technical rule, elaborating on it in multiple related areas and then, just when you thought you’d understood it, hitting you with a convoluted list of situations where it does not apply. Often the scope of exceptions far exceeds that of the rule itself. It’s the code-speak equivalent of a double negative.

On occasions you can find exceptions to the exceptions to the rule. There are some of the hardest types of code requirements to understand; effectively a triple negative. When readers come across these expressions, it is easy to start tuning out and completely missing the message. We found quite a few of these in pressure equipment codes.

Finally, the GUNNING FOG INDEX

In the world of linguistics, the best test for assessing readability of a piece of text is the Gunning fog index. It works by looking at how many long words, complex phrases and various sentence structures appear in the text and rates it by an index number between Fog 0 and Fog 20.The higher the index number, the more difficult it is to read and comprehend. There are numerous ways to interpret the results but overall, a fog index greater than Fog 12 is considered difficult. Above Fog 16 is considered fogging near impossible to understand.

You can try it for yourself on ‘fog index interpretation’ websites (yes there are such things). Just copy and paste a section of text in and it will calculate the fog index for you so you can impress your friends.

Trying this on technical codes and standards gave some surprising results. Some complex-looking code clauses produced a result of Fog 8 or less whilst some more straightforward (to us) technical paragraphs produced Fog 14+.Altogether the results were inconclusive , probably because Mr Gunning didn’t have technical standards in mind when he worked out his index algorithms.

What to expect in the future

If you believe the predictions of our linked article :Codes and Standards Futurewatch then code gobbledygook and doublespeak is set to be less of a problem in the future than it is at the moment. Once the current last hurrah of the attempted harmonization and generalization of prescriptive technical standards across the world has faded out, their replacement with goal-setting standards will be lacking opportunity for gobbledygook and doublespeak to thrive. Either that or goal-setting standards will comprise nothing but gobbledygook and doublespeak so their definitions will cease to be recognized, thereby getting rid of the problem.

For further reading on this most tedious of subjects try the following search terms:

ASME/EN/ISO code style guides. Yes there are such things

ROILA: Robot interaction language

Doublespeak examples

This article is the work of the Interviewer. We thank them for their contribution to Matthews Integrity hub: HEAD OFFICE