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: https://twitter.com/jaybazuzi/status/534470023088050177

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:

• Conway's Game of Life
• Growing Object-Oriented Software Guided by Tests
• This is the origin of "Tell, Don't Ask" and Mock Objects
• Understanding the Four Rules of Simple Design
• Discount available for Coderetreaters
• Arlo Belshee's blog
• Promiscuous Pairing and Beginner's Mind
• Strong Pairing
• Nobody Ever Gets Credit for Fixing Problems that Never Happened
• Embedded agile project by the numbers with newbies
• Mob Programming
• Time Laps Day of Mobbing