The fine art of blame allocation
By Sean Mc Grath
What do you do when the system you are using does something it shouldn't do? Who do you blame? How do you zoom in on who, or indeed what, to blame for the problem?
Note that I am purposely using the phrase 'blame allocation' as opposed to the more pastel-colored phrase 'fault detection'. You and I both know that, in the real world, the name of the game is to ensure that the problem is diagnosed as having come from 'over there' and preferably (deluxe version) 'that other guy over there'. None of us wants to be at fault. None of us wants to carry the can. 'Please, please, please', we think to ourselves, 'let it be someone else's problem.' This is just human nature 101. The social compliment to our rational thought processes.
Back in the days of 'green screen' computer terminals - days which I'm long enough in the tooth to remember all too well - blame allocation followed a very simple algorithm. Firstly, check that the terminal is plugged in to both power and network connection. Secondly, check that the tube on the terminal can display text okay. If both of those are fine then it is (oh joy!) someone else's problem.
The reason for the simplicity of blame allocation in this scenario lies in the fact that there are so few moving parts in a mere terminal. Its job is so simple, its software - if any - is built-in and unchanging -what can go wrong? Very little.
Skip forward a little bit to the PC era and of course all this changed. In return for a much richer user experience the no-free-lunch-police ensured that blame allocation became a whole lot more complicated.
What can go wrong in a PC with a full operating system and a full set of user installed applications? Whew! Where to start? Sometimes I'm amazed that we get any work done at all with PCs given the vast increase in the complexity lurking within kicking distance of the user's keyboard.
Skip forward a little bit more to the Web era. All changed again. More accurately, perhaps, the blame location pendulum swung back the other way significantly. Although you still had your full PC with its full operating system and a full set of user installed applications, the pre-eminent application became the web browser. Web browsers are a little like software versions of green-screen terminals. The very fact that they are merely browsers - like mere terminals before them - made blame allocation a lot easier. Most of the time. Almost all of the time, if a web application does not work it is not a bug in the browser.
The blame allocation checklist goes something like this. Check that your browser is working (hint: connect to Google - it is always up and running.). After that the problem must be 'over there' on the server side - someone else's problem.
Skip forward a little bit more still - we are nearly in the present day now - perhaps a teeny bit into the future. Browser development appears to be leaning more and more towards adding more and more client-side functionality into the mix again. The result? A swinging back of the pendulum in which the user's side of any application is 'thicker' with more things that can go wrong.
Blame allocation is about to get a lot more complicated again. The machine under the user's fingers will become a magnet for a whole new family of web-application problems. Will users consider that the increase in functionality will justify an increase in user-side blame allocation?
It will be interesting to see. In the leap from green screens to PCs the benefits from the user interface perspective were spectacular. Users voted with their fingers. Will the same be true this time around?