Guest Post from a CodeBoy: The Five Stages of Debugging

 In her previous post, the Cranky Product Manager unloaded on Code Boys & Grils who don’t fix their damn bugs.  She dropped the eff bomb and everything. Indeed!

This post is the flip side. The developer’s point of view when faced with a nasty bug.  And it’s an extremely well-written piece by a Code Boy who is  a reader of this humble and cantakerous blog.  

This post is required reading for product managers. And the Code Boys/Girls will probably like it too.

(Oh yeah, go visit Quantum Whisper.  The Cranky Kid loves them so much s/he stopped mid-tantrum and calmly whispered, “Mother, I can’t be expected to do agile product management without 1) candy, 2) my teddy bear, and 2) Quantum Whisper. I can’t and I won’t.”)

——————-

The Five Stages of Debugging

by A. Working Coder

Being confronted with a serious and difficult-to-diagnose bug can be one of the most traumatic and stressful experiences of a professional programmer’s career. Those who have been through such an ordeal rate the stress as on a par with that accompanying serious injury, divorce, or the death of a family member.

Researchers who have studied the psychology of computer programming have lately constructed a framework to understand the stages through which the programmer’s mind progresses as she/he works through the difficult process of resolving a bug. These stages are similar in concept to the well-known Kübler-Ross Stages of Grief, and for similar reasons. Like death and its attendant grief, fixing a bug is a process initiated by an event, at first unbelievable, which causes great anguish in the affected mind. However, this event must eventually be grappled with, endured, and brought to a satisfactory conclusion. Understanding the stages of bug fixing will make us better prepared to survive, persevere, and eventually bring closure … to our bug queues.

STAGE 1: RESISTANCE

How you’re feeling: Skeptical. Offended. Petulant.

1. Ignore it.

Maybe it’ll go away.

2. Mark it as “Works for Me”.

Maybe it was user error, or a local configuration problem. Yes, I’m sure that’s what it was. It’ll just go away.

3. Call it a Glitch.

I think it was just a weird one-off that nobody will ever see again. There’s no point in figuring out what went wrong. The {database/network/browser/something} hiccuped and that’s all this was. It won’t come back, I’m sure.

4. Hide.

I’m taking a couple of days’ sick leave. Maybe they’ll assign the bug to somebody else.

5. Mark it as “Working per Spec”.

Hey, look, I just implemented what was spec’d. If they want to change the behavior, UI will have to update the spec. Maybe they’ll decide they can live with it as-is.

6. Demand More Information.

I can’t do a thing with this bug until and unless I see the error logs for this particular exception scenario.

7. Assign it to another team member.

I was getting badly-formatted data from that other module, that’s the problem. Give it to the guy who maintains that module. I could check for that one weird corner case in my module, but the proper fix is for that other guy to make his code correct. He’s offshore anyway, so I’ll never have to face him.

STAGE 2: ACCEPTANCE

How you’re feeling: Resigned. Defeated. Annoyed.

1. Accept it.

All right, all right, all right! It’s my bug. I’ll fix it.

2. Put it on the bottom of your queue.

Maybe I can find another job before I’ll have to fix this bug.

3. Bargain with your manager.

OK, look: I could fix it the right way, and that will take a month. On the other hand, I could apply a band-aid to the problem, which won’t really solve it, but it’ll make it go away as far as the end-user is concerned. And that will take a couple of days.

4. Mark the bug with an outrageously padded estimate.

God, I hope that’s enough time.

STAGE 3: ENGAGEMENT AND DEPRESSION

How you’re feeling: Giddy. Light-headed. Nauseous.

1. Initial Research.

I can do this. I can do this! All it takes is a little organization, a little focus, a lot of caffeine, and a little time. I can do this.

2. Befuddlement.

Shit. This is unbelievable. I can’t make heads or tails of this code. It’s a mess. It’s a mystery to me how this code could even compile, let alone work. What chance do I have to figure out how it can fail?

3. Hide Again.

Look. I’m sorry. I had to have my appendix removed. Again. Yes, now that you mention it, I did used to have two. Now I don’t have any. Happy now?

4. Bitching.

Well, what did they expect, anyway? Trying to do this without so much as a decent debugger. What am I, clairvoyant? I had better debugging tools on my Commodore 64!

5. Spitballing.

What if I try … this? Nah, that doesn’t work. How about … that? Nope. How about … that? Shit, that makes things worse.

6. Despair.

I’ll never fix this bug. I’m a lousy coder. I’m stupid. What am I doing here, in a place full of smart people? Sooner or later they’re gonna catch on, and then I am finished around here.

7. Humiliation.

My manager asked me why I’ve taken the better part of a month to fix a bug I’d spec’d out as taking a couple of days’ worth of work. I don’t know how to read the logs and I broke my own build scripts. Now I’m afraid to ask for help because it’ll just make me look stupider than I already do.

8. Panic!

This thing is way more complicated than I thought it would be! The parts I thought would be really hard turned out to be really easy … and the parts I thought would be easy turned out to be a complete rewrite of about a half a dozen classes. Why did I ever tell my manager I could do this?

9. All-Nighter(s). Withdrawl from friends and family.

(incoherent mumbling, punctuated by bursts of loud profanity.)

STAGE 4. POSSIBLY FOOLISH EUPHORIA

How You’re Feeling: Grateful. Relieved. Awfully Impressed with Yourself.

1. Revelation.

Oh! Now I see how to do this…

2. Write the correct code.

I am so good. I am a coding machine!

3. Test it.

Yes! It passes that test. Yes! It passed that test. Boo! It fails that test. And I have no idea why…

4. Hide the test failures.

It’s a totally unrealistic corner case anyway. Nobody will ever see that in the field. It was really a pointless test.

5. Check it in.

I’m awesome. Is there pie in the kitchen?

6. Close the bug.

I heard there was pie in the kitchen.

STAGE 5. GRAPPLING WITH THE DEFINITION OF “DONE”

How You’re Feeling: Twitchy. Nervous. Superstitious.

1. They’ve Reopened the bug.

Really? They found another way to break it? Shit – it’s that corner case I swore would never come up.

2. Fix the fix.

Yes, I’m even checking cases where the employee age is an imaginary number, just to be sure.

3. Close the bug.

Yeah, bitch. You’re closed. Once and for all. Now stay dead!

4. Vow to never take on such a task ever again.

5. Realization that you are now considered the expert on that module.

Oh no! Now I’ve got three new bugs on that module.

At this point, you are expected to GOTO: Stage 1.

Furthermore, as a working coder, you will DO_UNTIL: Death, retirement, or promotion into management.

173 comments

    • The Cranky Product Manager

      Hi Saeed, you’re hardly the first person to write an article that uses the Kübler-Ross Stages of Grief as a basic structure. I can assure you my guest poster had no knowledge of your article before writing his/her article.

      Plus the content is quite different. The main similarity is using the Stages of Grief construct.

  1. Ophir Kra-Oz

    I would argue that there are two types of developers.
    Those who prefer debugging (sort of detective work) and those who prefer coding (the writers).
    The psychological type can be quite different and sometimes it is worth an effort to split the problem.
    Really smart QA can debug an issue and isolate it while the developer than has to fix it.
    Naturally when the bugs are extremely hard ( see my post on the hardest bugs in the world :) ) http://ophir.wordpress.com/2010/05/29/the-hardest-bugs-in-the-world-part-one/ it takes a team to resolve the problems. Even the product manager can help out.

  2. Howard

    This is excellent. As a product manager who is often called upon to deal with (aka help) clients who experience these types of issues, I think we also could call on these same stages even more than what set off Cranky in the first place. When we hear about the bug, when we hear how ridiculous it is, how hard it is to fix, how magically it is fixed, how it isn’t fixed, how development / qa missed it because they didn’t understand what the customer was doing that broke it, and then of course how it comes back to PM because what we asked the product to do wasn’t what the customer wanted to do because we couldn’t possibly have known that strange case but we should have, and then finally when the customer escalates, and then we finally get a feature into the next release to solve it. Oh, and when that feature has a bug…..

  3. Gaz

    While I recognise this kind of cycle (as a Code Boy myself), I feel that it more represents the psychology of an beginner coder and (with luck) as your career progresses you learn to acknowledge that:

    – bugs happen to everyone
    – there’s no point taking it personally
    – everything can be fixed with sufficient effort and experience

    and take these things as they come along. I guess the comments about it being as stressful as a death or whatever are tongue-in-cheek; really annoying difficult bugs will just come up time after time and it’s the job of the coder to fix them.

    Excessive stress will mainly come from overly pushy and/or ignorant managers.

  4. Boldly Mocking

    I just love your blog. As a website product manager where do agilefall in my UnhealthyCare company, it’s priceless to giggle over the simple pleasures, such as the angst of the bug and the finger pointing and lack of ownership in fixing it.

    Love the corner case that would NEVER get hit!

  5. Pingback: 98 Content Marketing Articles to Make You an Insomniac | Unbounce
  6. Pingback: pretty || inspiring || funny | Pearltrees
  7. Pingback: Project Management | Pearltrees

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>