Baseball and software
I have a talk at sasqag last Thursday. I got a lot of great feedback and comments, and I got a chance to talk about some of the ideas I've been batting around for the last year or two. (I spoke of how far software test has come during my career and how far it still needs to go, and gave some examples of things test teams could do to find bugs earlier - all stuff I've written about, or will write about shortly).
In addition to the stuff I had planned to talk about, for some reason I added a bullet point on defect (bug) prediction. I didn't have another slide, but I thought I'd say a few words (or just remove it at the last minute).
On the way to the talk, I was listening to game 7 of the Cardinals-Mets series. I was thinking "this is a game 7 and Detroit won in 4. I wonder what the historical stats are when a 7 game series winner plays a 4 game series winner in the world series." I haven't head yet, but I know someone has that statistic. As a big baseball fan, I know that baseball, more than any other sport, relies on statistics. Batting averages, on base percentage and era are only the tip of the iceberg. There are major stats that everyone knows, and obscure stats like number of walks against a right handed starter under 25 years old on day games in August when the wind is blowing from the southwest. But in baseball, these statistics are much more than trivia. Baseball managers constantly refer to statistics to determine when to change players, when to attempt a steal, or what pitch to throw. Historical data has a tremendous amount of value in determining how the nuances of the game are played out.
In the software world, despite the amount of statistics (bug data, test cases, performance results, etc.), we aren't nearly as good at using data to predict future behavior - in fact, we kind of suck at it. Most teams don't even see bug prediction as something that is possible. Some teams take a crack at it and measure bug density (number of bugs per thousand lines of code) on one product, and assume that they will generate somewhere near that amount for other projects. This is sometimes an accurate predictor (and sometimes not) of whether the bug tracking activities are on track. Other metrics, such as code churn or code complexity are also often used as methods of predicting where bugs may occur. There are probably many more metrics that can be used to predict where bugs are, but I don't think there are many people trying to figure it out. I know I plan to spend some time thinking about this, and hope many others are as well.