The following belongs, in tone and register and field of reference, to a broad class of humorous utterance related to the habitus and mores of Windows software developers working in corporate environments in the very earliest part of this century. I can laugh about it now, but at the time it was terrible…oh…

> Q: How many software developers does it take to change a lightbulb?

> A: I’m sorry, that’s a hardware issue.

>> I jist don’t git it! First of all, it may be the jargon…

It’s about blame, and shifting it away from oneself as deftly and

decisively as possible.

It goes like this. You write some software. It runs superbly on the

machine you wrote it on. If ever a glitch should occur you just dive

into the trace files, or run the debugger, or restart the

thingummy-doodadulator module, fix whatever trivial hiccough it was

that temporarily interrupted the living marvel that is your fabulous

digital masterpiece, and carry on blithely as if nothing has happened.

Oh joy, oh happy innocent days.

Then the dreadful moment comes when your marvellous creation has to be

deployed into a production environment. Meaning, in the first

instance, that it has to run on someone else’s computer. Possibly a

lot of other someones’ computers, all with their own peculiar

configurations…

All the time you were developing, you were running with full

administrator privileges over your own machine (developers are *way*

important, nothing less than Total God powers will do). A bunch of

stuff breaks straight away, because your software will only work if

the user has Total God powers too, and it’s the job of any system

administrator worth his salt to disempower users to the greatest

degree commensurate with their actually getting any work done (and

ideally even more than that - the wisest policy really is just to take

their computers away from them and make them work with abacuses and

scraps of paper. Sitting in a circle. On a dirt floor. Keeps the

blighters off the internet, at least).

So you fix the issues to do with system privileges, having failed to

persuade the sysadmin that its absolutely essential that all users of

*your* hyper-important and mega-business-critical application be given

the rights to erase all the data on the shared network drive, change

their Windows wallpaper to images of Jade Goody morphing into a pig,

download arbitrary spyware from Russian porn sites and change the

managing director’s password to 1m4W4nK3r. Great, now the users can

use your software. Great: now the users can break your software.

Testing? We were supposed to allow time for testing?

Now it’s time for all the little hiccoughs you used to smoothe over

without thinking about it to happen to your users. Who, mirabile

dictu, do not have Visual EasyDev Grand Poobah Edition installed on

their desktops, and consequently would not be able to run a debugger

even if they knew what one was (I discount the users who *do* know

what a debugger is, the sarky know-it-all bastards…). When a

hiccough happens to them, they don’t get magically transported into

some special hiccough-fixing mode, complete with breakpoints and stack

traces and CCTV footage of rogue variables making their getaway. No.

Their computer crashes. And it’s your fault.

Dealt with the hiccoughs? Delivered sufficiently withering put-downs

to the sarky know-it-all bastards who said things like “well, I’m no

expert obviously, but it looks like you’ve failed to handle that

exception from the asynchronous worker thread, which has consequently

been left in an inconsistant state leading to nondeterministic

behaviour probably caused by a race condition in the out-of-process

RPC marshalling code”? Congratulate yourself on your fine

troubleshooting skills. Truly you are a credit to your profession.

Unfortunately there are a few issues remaining…

One is the user who emits electromagnetic radiation that causes any

computer within a ten-metre radius of them to exhibit erroneous

behaviour so weird and undocumented that even Google hasn’t heard of

it. Fortunately for you, their colleagues have long since identified

them as a freak of nature, and will be supplying them with an abacus

and a patch of dirt floor to sit on some time in the immediate future.

More worrying, however, are the users sat at the bank of PCs in the

corner of floor 3, who have only 64 megabytes of RAM on their pitiful

and ancient machines, and who complain that your software rapidly

consumes all available system resources and then hangs, interminably,

while they twiddle their thumbs and arrange to call their customers

back at a more convenient time, like when they have an abacus handy.

Frankly, it’s an insult to your craft and your integrity as a l33t

h4xx0r that your software should be expected to function at all on

such dilapidated hardware, and it is through gritted teeth that you

recommend they all upgrade to a level of computational capacity more

appropriate to the demands of modern business applications. Memory

management? That’s not your problem - the programming language you use

has nondeterministic garbage collection, ferchrissakes, it’s so

incredibly efficient even you have absolutely no bloody idea how it

works - and anyway, what are a few little memory trickles between

friends (hugs super-high-spec developer workstation with fierce pride

tinged with erotic longing)? Nope, that’s a *hardware* problem, and

quite out of your domain of professional concern. Better get tech

support to take that nasty little grey box away and replace it with

something more stylish…