Why do we still need psychic programmers?

Before I answer that questions – why do we have end users who need to be psychic?

I’ve been on holiday with my family and one of my family (let’s call her my cousin) was ranting on about a wonderful new, agile, cloud based tool for entering data about patients. The rants were because the tool was not intuitive, and now they have to enter the data in both the old tool AND the new tool because the old tools can’t read the data in the new tool. I kept hearing comments like “how was I meant to know that – I am not psychic”
I was mulling over this over as I stood on the platform waiting for a train to take me to London. I had a first class ticket. I arrived on the platform, the sign to the left of me said first class at the front of the train, and the the sign to the right of me also said first class at the front of the train. It didn’t say which way the train would be going, so how was I to know which way to go – left or right ? I am not psychic! In Japan they have a sign saying “12 coach train. Coach K” where the train door for coach K will be – this is great! The people in the UK who develop the signs, clearly use the platform every day, so automatically knew which way the trains were heading. Us poor users have no idea. You either had to ask, or there was a 50% chance you went to the wrong end of the train and had to sprint along 12 coaches to get to the other end. Our train was almost delayed by a old person who raced as fast as his two legs and stick could go, to get into first class.

Wikipedia said
A psychic is a person who claims to use extrasensory perception (ESP) to identify information hidden from the normal senses, particularly involving telepathy or clairvoyance, or who performs acts that are apparently inexplicable by natural laws.

Back to my ranting family.
Some web based tools save data every 5 second so if you have a problem, it can show you a draft version. My cousin said she entered lots of data in the new tool and was ready to save it – but there was no save button, so she assumed it was auto saved. There were some icons at the top of the screen. The icon pictures had no relevant to any tasks, and there was no hover text to say what she did. (She said one icon looked like the clay dog Grommet from the Wallis and Grommet films). She pressed an icon and went onto the next screen. After a few minutes she found she needed to update the previous data. She could not find a way to go back, so she quit and re-entered the tool. Non of the data she had entered was there. She phoned the help desk and the conversation went like
Cousin:       It lost all of my data
Helpdesk: Did you press the save key?
Cousin:      There is no save key
Helpdesk: It is on the right hand side.
Cousin:      No it is not.
Helpdesk: Try maximising the window
Cousin:      I see a save button now. How was I meant to know there was a save button hidden to one side.
Helpdesk: Every one knows it is there
Cousin:      Well I didn’t – I am not psychic. There were no horizontal scroll bars to indicate there was more info to one side.
Helpdesk: It is in the help text – did you look there
Cousin:      Why would I look there ?
Helpdesk: To tell you how to save the data
Cousin:      I expected it to autosave – so it could be recovered in the case of problems.
Helpdesk: It doesn’t do that.
Cousing:    If I had pressed the help button – would it have saved my data before displaying help?
Helpdesk: Only if you had pressed the save button.
(goto to line 1)

Cousin:       What do the icons mean?
Helpdesk:  The one with an H in an circle – means help
Cousin:       Ah in the previous tool this meant a list of hospitals.
What is this circle with an arrow – like a refresh icon in a browser
Helpdesk: That is the start again button. It deletes all of the stuff you have entered
Cousin:       You mean like Ctrl-A ( to select all the text) delete?
Helpdesk:  Could be
Cousin:        Is there an undo-delete button?
Helpdesk:   No – you have to save the data often
Cousin:        How was I to know that – I am not psychic!

Cousin:       Which is the stop icon?
Helpdesk:  The red one
Cousin:        Which one is that
Helpdesk:   Are you colour blind ?!
Cousin:       Yes
Helpdesk: Well it’s the one next to the green icon.
Cousin:      Which one is that?
OK this is not all 100% true, but it is based on comments from my family and our struggles to do our jobs despite the tools available to us.

It makes me think these tools are designed  by the Dilbert character Mordac, the preventer of information services.

How is this relevant to MQ and the psychic programmers?

I was contacted by someone looking for assistance.
Her company has some guidelines on how to program with MQ. These looked great, with a lot of detail – it must have taken weeks to write it all down.  There was a section on each area of MQ programming.
For example “Use of persistent messages. You should use persistent messages if your data is important. If you cannot afford to lose data then make the messages persistent.”
Her arguments went along the lines of

• If it was not important, I would not be working on it. I am working on it,  therefore it is important, so all messages must be persistent.
• This is an audit type message – I think it ok to lose the occasional message ( < 1 %) but not ok to lose 10% of the messages. I cannot make a message 99% persistent.

Another point she raised was that she was told to put a message to this queue to go to the server, and wait for a response. How should she know what persistence to use as it was not documented.

Often there are no guidelines easily available to help application programmers. For example

• There may be no guidelines
• The guidelines are not easy to find
• The guidelines are not clear
• The guidelines are written from the wrong viewpoint.
• The guidelines may be very detailed – but too many details may make it less clear.

You can avoid the need for psychic programmers by having clear guidelines, and business template – and not at the MQ capability level.

For example

•  Business template 1 – request reply model
  The messages contains important information. If messages cannot be processed then you need logic to be able to retry and possible duplicate requests.
  Each business application has queues defined specifically for it, use these queues.
  For messages you are unable to process they must be put on an error queue.   This queue must trigger an alert, and you must have a process in place to process these bad messages

So how do you avoid the need for psychics?

• Make sure your information is easy to find
•  Write the information knowing the lowest level of knowledge your audience has. Put yourself in their position.   You know it is obvious because you already know the answer.
• Discuss it with your users, or people who support you, get feedback and update your documents.
• If the rules do not match your environment, change the environment, or change the rules!