Project Communication

Over on the Software Testing Club I've been talking a little bit about communication within teams and it's been interesting to see how passionate the responses have been.

We've all been there – been given a series of planning and design documents for our project.  They're very long.  And dull.  And when you're reading it, it goes

“The system will readily maximise future leverage in the marketplace under the caviat that increased technical processing will accelerated – blah blah blah – oh this is so boring”

Yup – and there's usually about 60 pages in that vein!

Over the last few years I've read some truly mindnumbing documents.  We then send them to the customer, and get really irate they never comment back on them.  Or worse still when we deliver and they go “why does it do that?” we go “but we told you in that 400 page technical spec!”.

Why are we making it so difficult?  Let's step back from the problem first and ask – how would we as engineers solve a similar problem of communication if we were dealing with a technical computer based issue?

So like the SOA examples I've talked about previously we need two computer programs to communicate how would we deal with it?

First off we should be going “why are we communicating”.  Most communications fall into one of what I call “the 3 i's” …

• Instruction – telling another party to do something
• Information – providing another party with data of some kind
• Inquiry – asking another party for information

So whatever we're communicating for the computer, it had to fall into one of those.  If it's not, then it's just waffle / overhead, and we need to bin it.

We then take a lot of time thinking about protocol – we want the messages we send to another system to make sense there, and likewise we want the information we receive to make sense to us.  We also know that brevity is key – if we make messages unnecessarily long, we know it'll consume bandwidth without really delivering any kind of value or service.  If not, then once again it becomes an unnecessary overhead.

We are super-optimised when it comes to dealing with communications between systems.

Why then are we so bad at communicating with each other?

No really we are!  We're so good at the rules of communications on computer systems, we know its a complicated minefield, so we treat it with respect.

But we've known how to write since school and been talking since we were about two.  Easy peasy, it just comes naturally hey?

And so we run meetings which constantly run overtime, but don't go anywhere.  We write reports which are too meandering and too technical for the audience, and no-one reads anyway.

No – no – NO!

Let's try this again.

Every email, memo, report we write needs to be tailored just as we'd design a computer message.

We need to make sure it has purpose – that it either informs, instructs or inquires.

We need to make sure it has protocol – that it conforms to an easily understood standard by the intended party, and has the information they need without unnecessary length.  That it is targeted for it's intended audience.

We also to use plain English where we can.  Sometimes we expand what we write with buzz words and jargon because we feel it gives a certain grandeur and polish to what we say.  I know many a person who's a bit guilty of using a “posh word” in not quite the manner they really should.  Instead of looking clever, they look stupid, and this can also mean confusion creeps into what they're doing.

If not careful we can become like some aging thespian saying “To be or not to be.  That is the question.  Whether tis nobler in the mind to suffer the slings and arrows of outrageous fortune.  Or to take up arms against a sea of troubles, and by opposing, end them”.

Most kids if you said that to would go “huh?”.  However if you said “Look shit happens.  Either learn to take it or give some back alright?”, they'd go “ah”.    Targetting for the audience you see.

Some of you might say that's not proper English, but then (and no offence, as I love his work), neither is Shakespeare these days.

Let's keep it simple eh?