Debugging and The Five Stages of Grief

As a programmer, you learn to accept bugs as a part of life. No matter how hard you try, there is no simple way to avoid them.

What separates good programmers from bad programmers is not only their ability to avoid bugs, but also their ability to deal with them when they arise.

When programmers are confronted with bugs in their applications, they typically progress through what psychologists call the five stages of grief.

These stages are a series of emotional states people experience when dealing with tragedy or loss in their lives.

It may seem a bit odd that something as common and benign as a bug could trigger this type of emotional reaction, but, in a way, it makes sense.

Our applications are like our babies. We create them. We raise them. We watch them grow, all in the hopes that, someday, they will be able to set out on their own (and make some money to support us in our old age).

It is natural that we are affected when someone tells us there is something wrong with our baby.

Oh no! My baby has an object reference error!

As a programmer, you must be able to overcome these emotions quickly and effectively. Otherwise, you can linger and stagnate in one or more of these stages.

Developers who recognize how their feelings affect their performance stand a much better chance of finding a timely solution to their problems.

With that in mind, let’s take a look at how the typical developer progresses through the five stages of grief when dealing with a bug:

Stage 1: Denial

Bugs? What bugs?

Bugs may be inevitable, but you sure wouldn’t suspect it from the way the average programmer typically responds to a bug report:

• “That can’t be from a bug in my code! I bet the .NET library is causing this to break…”

• “Are you sure you tested this right? You’re probably not using the application correctly.”

• “That’s impossible! My code is perfect!”

The mere suspicion that a bug may exist can put a developer in defense-mode. It is as if bugs were personal affronts to our honor that sullied our good name.

It’s a funny reaction because deep down we all know that the bug probably does exist, but that won’t stop us from clinging onto the hope that perhaps this time our application is working as expected.

There are some among us who will happily bury their heads under the sand for as long as humanly possible. But, to our credit, most of us quickly overcome this stage.

Luckily, most bugs that are reported are reproducible, which leaves a developer no other option but to address them.

Stage 2: Anger

Now this is a stage we could spend some series time in…

• “Why wasn’t this caught earlier in testing!?”

• “Why does so-and-so’s code break so often!?”

• “I’m already busy. Now I have to deal with this!?”

• “GRRAAAHHHHHH!!!”

Most programmers are very well acquainted with this stage. We all know how cathartic it can be to let out our inner code monkey rage.

In the end, we need to recognize that all the screaming and yelling and breaking of keyboards doesn’t solve anything. All it does is kill time, burn bridges, and make us look like whiny jerks.

In the end, we’re still left staring at the same bug, only now we have even less time to fix it.

Not to mention the substantial damage control we may have to run after that exclamation point-filled tirade we sent to the company e-mail list.

Yeah…this year’s company Christmas party is going to be mighty awkward…