On regressions
My friend Nate asked me via email:
You said: "I tend to get nervous when the answer to 'How often will the user exercise this code path' is 'all the time.' If nothing else, changing an often-used code path increases the risk of causing a regression. As much as I hate shipping software with a bug, I hate shipping software with a regression even more." What is a regression?
A "regression" (really, a "regression bug") is the recurrence of a bug that was previously fixed.
Consider a product in which Bug A was fixed weeks ago. Then, in the course of fixing another Bug B (which may be completely unrelated to Bug A), the fix causes Bug A (or a very similar bug) to re-appear in the product. The recurrence of the previous bug is a regression. And we would say "fixing Bug B caused a regression of Bug A."
Sadly, these bugs (i.e., regressions) are more common than you'd think, especially as the complexity of software grows, and more especially as the dependencies between different independent software teams become more numerous. (This is somewhat analogous to the increase in communications required as you add more people to a software project, as set forth in Brooks’ Law.)
In some cases, fixing Bug B might actually introduce several bugs, one or more of which might be regressions, and the others which might be entirely new bugs. So there’s a possibility of setting off a kind of avalanche of new bugs and old regressions. This is more of a problem with fragile (some would say poorly-designed) software, but it becomes more likely for any software system as complexity increases.
The bottom line is that you want to make sure that fixing a bug results in a net improvement in the quality of the software. (For simplicity sake, define "quality" to be inversely proportional to "the number of known and unfixed bugs").
Having a regression means (simplistically) that you've at best made no net improvement in quality, and at worst you've actually reduced the quality of the product. It seems counterintuitive that fixing a bug can actually make product quality worse, but believe me--it is simply a fact of life in software engineering.
Keep in mind that the cost (in dollars, when you consider time value of money) to fix a single bug increases approximately geometrically as the age of your product increases. Roughly, you can consider the cost of fixing 1 bug during normal, pre-release development to be 1.0. The cost to fix that same bug after a "code complete" milestone becomes 10.0, the cost to fix it after a public beta release is 100.0, and the cost to fix it after RTM is 1000.0.
Login with LiveJournal or OpenID