Discipline & Punishment - A Programming Perspective

The Illegal Operation

In the world of software we have the concept known as an 'illegal operation'. You may remember this from the old Windows 95 days

When this happens it is usually due to the application attempting to access an area of memory already reserved by another application, or by the operating system itself. The operating system acts sort of like a 'COP' recognizes the instruction and calls it out of play (closing the program down).

Now we use the term 'illegal', but not in the strict sense of the word , no laws were broken, the real police aren't going to show up on your doorstep. It is more like if you accidentally "stepped on someone's toes" at work by preforming a task that was their responsibility and not yours...and this is where the analogy becomes particularly interesting.

When the computer program 'steps out of bounds', it has zero  'awareness' of its actions. It was just following the code that was written. Probably some programmer forgot to properly allocate memory to a variable before using it. If the particular problem is within an area of the software that is not called very often, many users won't even notice it (and this is why made it past it past testing phases).

Users, however, can be very annoyed by these errors, mainly because it means whatever they were just working on is now lost forever (never mind the fact that they have been typing up a document for 4 hours, and never once thought to hit Save). They can yell and scream all they want at the software, because it has no 'feelings', it isn't going to be hurt. Telling the software "try harder next time" will make no difference at all. It is software, it just does what a programmer told it to do.

Illegal Instructions = Bugs in the Code

..and like all bugs they need to be prioritized according to their relative  importance and frequency. A bug that only occurs for 1-2 users every 5 years is not going to get repaired as fast as a bug that occurs for hundreds of users many times a day.

Users (as angry as they can get), will put up with a certain amount of this frustration. I have seen some users, oddly enough, who turn to blaming themselves for the problem, thinking it was their fault for 'pushing the wrong key' or wondering what they should have done differently to prevent the error.  Of course, this is not true, the fault lies with the program, particularly the bug that needs fixed..not the USER.

Now once a bug is identified, and prioritized, a programmer looks at the code, identifies where the error is, and writes code to fix it. Sometimes this actually fixes the problem, other times it does not and still other times it fixes the problem but creates 10 new problems. Such is the nature of programming.

Programmers solve problems by:

 a) Evaluate: Identifying the problematic code,
 b) Fix: Apply changes to the code to prevent it from happening
 c) Test: that the change now produces the expected original behavior

My Point (and yes I do have one)

In NO  cases does a programmer 'discipline the code', tell it to 'try harder', 'be better'. The code does not get a 'time out', heck it doesn't even get a compliment when actually doing the 'right' thing.

Like people, software exhibits behaviors - some are intentional, others are not, but behavioral management techniques like positive re-enforcement, punishment/disciplinary action, [while they may work to train your dog not to pee on your carpet] are foolish to apply to software programs.

The programmer understands this, but not always necessarily the user. The user feels annoyed, frustrated, even angry. The user was likely up against some deadline and now they are going to miss that deadline -  all because of some stupid bug, and the tech guy just shrugs and asks 'have you tried turning it off and back on again?'

Sometimes I think if we actually gave users a punish button and allowed them to press it when software crashed, they would push that button like crazy just to make themselves feel better (even though it would do absently nothing)

The Lesson

I suggest the next time you are feeling annoyed at your employee, your colleague, your spouse, or your friend because they did "X" or said "Y", or stole your favorite teddy bear - or whatever is upsetting you -  try thinking about NOT from the perspective of the annoyed USER, but instead from the perspective of the programmer.

Oh  WOW -  You found a 'bug' exists in the code of the relationship!

1) Evaluate the priority (ASK: is it frequent? - is it important?)

2) If it is a priority (ie: it continues to occur over and over)

          a) Evaluate: What is the problematic code (where is the misunderstanding?)

          b)  Fix: Apologize as necessary, Agree on a changes to prevent it from happening again

           c) Test:  Verify the next time we get the expected behavior

3) Recognize that the attempted fix may not work, or may only work partially, or may even create 100 more bugs hiding from view.

If we can't ever produce a single computer program with zero defects, how in the world can we reasonably expect to fix problematic behavior in people by telling them to "try harder" or they will be subject to disciplinary action.!!