The Misuse and Proper Use of Metrics

When software developers first looked for ways to measure their success, they measured “lines of code” (LOC) or “thousand lines of code” (kLOC) as projects got bigger. The theory was pretty straightforward—if you had a highly productive developer, they would be cranking out some phenomenal amounts of code. Given that most of the time developers write one expression per line of code (obviously complex conditionals consist of more than one expression, but then again a closing scope-block brace doesn’t have any expressions, so it sort of evens out), LOC seemed like a pretty easy way to measure which developers were actively contributing to the project’s success, and which weren’t.

Developers are a pretty analytical and creative lot, and it didn’t take long before people figured out that if they are held accountable to metrics—and only to the metric—then the best thing to do is to optimize in favor of the metric. Pay me by the kLOC? I’ll use code generators to create lots and lots of code. Pay me by the number of features shipped? I’ll churn out feature after feature and never worry about bug fixes. Pay me by the number of bugs fixed? I’ll not only focus entirely on bugfixes (and the easiest ones at that), but I’ll look to populate the bug tracker with new bugs that are quickly fixed—and maybe even slip a few bugs in during development so I can find them and fix them. (The last example may seem a bit ...