User pain and developer shame

There is the concept of User Pain. Useful concept which I’ve used at work. It’s not perfect, might need tweaking for each situation but works well.

In a nutshell: given a software bug it is possible to quantify the pain caused by the bug to all the users based on the type of bug (crash, major, minor, etc.), priority (will the users affected be blocked? or just a small cosmetic problem?), and likelihood (how many users are affected? a few or many?).

But I’ve created what I called the “Developer shame”. It’s a new concept. I thought about this when I felt ashamed we hadn’t fix a bug. It was a small one, easy to fix, only a few users were affected (but we had some requests every now and then). It was one of those bugs that when someone mentioned it everyone wondered “why we didn’t fix it? Easy to fix, and it’s not the first request!”.

Getting some inspiration from the User Pain blog post I’ve assigned some points:
How easy is to fix (always for a single developer)

• 2 points: 0 tea breaks required to fix it
• 1 point: 1 tea break required to fix it

(more tea breaks: out of scale)

How do you respond to the affected users

• 2 points: with a workaround that the developer could have implemented
• 1 point 1: with a generic message

Do you know how to fix it?

• 2 points: you just need to sit down and type the solution
• 1 point: you think that you know but there is a small part that you might need to check

What’s the risk

• 2 points: there is no risk when implementing this. Just new code that doesn’t affect existing code
• 1 point: some risk implementing this (might need some refactoring, changes some existing code)

Just add up the points: the scale of developer shame is from 0 to 8.

I suggest that if it’s 7 or 8: please go and fix. Being ashamed of bugs is not good. Then one feels guilty, and feeling guilty is not good feeling either. It’s better to feel proud of your software.