Codermetrics

Timeout for an Example: The Magic Triangle (Partially) Debunked

A lesson from one set of projects provides a thought-provoking example of how metrics can challenge your assumptions. This example involves a team that worked on a rapid product schedule, typical for an early stage start-up, meaning that we were delivering quarterly releases with new features, enhancements, and bug fixes. There were ten coders working on the project.

I had an assumption about the contents of each release. Looking back, I’m not really sure where or when I arrived at the assumption. I guess it just seemed like common sense, but it’s one of those oft-repeated assumptions that you come to believe is based on objective fact and experience, when really it is based on something someone told you.

Given the hard deadlines, I assumed that the more we tried to cram complex features in the release, the less quality we would get. Following this logic, I believed that a quarterly release with more complex features would also have more bugs. My belief was based on a concept that you probably have heard of, the software development “magic triangle.” This adage says that, among the three choices of more features, tighter schedule, and higher quality, you can pick two and the other one has to give. Since we were already committed to a tight schedule with many features, I assumed if we added more features, then lower quality would result. Makes sense, right?

To measure the contents of each release, I rated every coder task ...