Monday, November 17, 2014

Measuring bug latency

Many people like the metric of “how long it takes for a bug to get fixed”, indicating the health of your code, your team, your process, etc.

What exactly do you like to measure? Consider these points in time:

1.       Bug is written on a dev machine.

2.       Bug is pushed to source control.

3.       Bug is deployed to customers.

4.       Customers hit the bug.

5.       Someone recognizes that it is, indeed undesired behavior.

6.       Bug report is added to the bug tracking system.

7.       Developer starts working on a fix.

8.       Fix is pushed to source control.

9.       Fix is deployed to customers.

I think most dev teams at MS would default to measuring 6-8. Customers would measure 4-9. I can imagine measuring 1-9.

Maybe I even add:

0.       Developer had an incorrect thought.

And before that:

-1. The stage was set, which gave rise to incorrect thinking.

Share your thoughts here:

Resources for Coderetreaters

I held a Coderetreat in Port Townsend this past weekend as part of the Global Day of Coderetreat. Thanks to all who showed up, and to The CoLab for hosting us so generously.

I promised I would post a list of resources that came up in our discussion. Here ya go: