29 April 2013

The Infinite Monkeys Approach

I once knew an expatriate worker in the Far East who was tasked with liaising with the office cleaners because he could “speak the language”. In theory this was a good idea. However, the cleaners were all profoundly deaf, so whoever got the job was going to have to learn or invent a sign language before they could begin, whatever languages they currently spoke. The assumption of competence being granted because of linguistic faculty is sometimes amusing when it happens in a second language (I ‘speak’ Mandarin, but that doesn’t mean I can quickly and easily understand a lecture about orthopaedic surgery in the language; I’d struggle to keep up with that topic even in English), but from a professional communicator’s point of view it is even more irritating when it's done in the workplace with technical documentation.

Recently I’ve been seeing some particularly bad examples of documentation. The kind of stuff that is so bad that it has passed the point of irritating users and is actively dissuading potential customers. What did it have in common? It was written by ‘experts’ – in the topic, not in communication. I wonder why it gets written like this, particularly when the time of specialist developers and engineers is taken away from their core duties to produce it.

What shocks me is that businesses already know that their geeks often work best when kept away from customers. It’s why they employ sales people to do the verbal communication that brings in sales... because customers want to hear about software meeting their requirements, not how cool the software is because the subroutines are all named after characters from Star Trek, deceased pets or steam trains.

I've also heard of ‘test’ entries into database products that have made their way into training and documentation materials, and even into the finished product. Sometimes these just hinder understanding (“test for empty field” isn't a good example to follow), whilst others can cause offence (“nutty as a fruitcake” as a mental health condition for example).

This criticism is not directed at developers, they do a job I couldn't do, and they do it well. It's directed at the person who decides that because their developers happen to speak English, they're going to save money and give them the documentation to write. As an approach to documentation management this is only marginally better than handing infinite monkeys, infinite typewriters (and marginally cheaper due to the resultant cost of infinite bananas).