Measure what you actually care about

Our three kids are currently 2, 4, and 6. We are starting to potty train the youngest. She's a cute thing, but you can imagine it's always a trying experience. Because I'm very anti-ivory-tower, and think the best developers are the ones grounded in the practically of everyday life (such as potty-training a two-year old), I can't help but think how this relates to software engineering.

Here's how: we found ourselves rewarding our daughter every time she successfully went potty. It sounded reasonable, but we remembered that it's actually misleading – we're rewarding the wrong thing. What we really want is not a two-year old that goes potty every 20 minutes in order to earn her chocolate-chip, but rather a two-year old that remains dry. Even two-year olds can figure out how to game the system.

This sort of misguided measurement is what often occurs in demoralized IT shops. For example, the main compensation is based on the number of bugs fixed or number of UI screens created (because it's easy to measure), but what they actually care about is increased functionality or quality. The irony is that this often encourages the exact opposite of what the boss really wants. Just like I don't want  a two-year old going "tinkle" every 20 minutes, I don't want developers gaming the system by fixing large quantities of irrelevant or duplicate bugs.

The blog post doesn't have a quick answer, I mainly just wanted to write about my daughter's potty-training adventures while she was taking a nap. But a quick approach is to focus on what you actually care about (say quality), and then work backwards thinking "what would high quality look like", such as less production complaints, les support time, less application down time, less developer time spent fixing bugs, etc… Then focus how to measure those things.