Other Regressions
(picture: The line at Staples shortly before it opened on Black Friday, it extended further than you can see here)
“Regression” is a term for a specific type of programming bug: A bug that is introduced into something that had previously worked. It’s also apparently a pretty popular type of bug, because even large, well-maintained projects have them: the OLPC software has a long list of regressions (and they’re shipping anyway - most of them aren’t big problems), and Firefox just released version 2.0.0.11 to fix a (cosmetic) regression in 2.0.0.10 (a security patch release which you should already have if you use Firefox).
Most of the time, regressions should be caught by unit testing, but for some reason weren’t. (This is one reason I don’t like unit tests much at the moment: if you know about a problem enough to test for it, you should be able to avoid it in your code.) But to me, regressions are pretty much a major reason for code segmentation: write one function that does one thing, and combine them to do other things. It should be reasonably easy to determine what inputs and outputs each function gives, and if it isn’t, that’s what JavaDoc, JSDoc, and others are for.
Overall, I really have to think that most regressions could be avoided by having enough simple functions doing well-defined things. However, that isn’t always possible or feasible, which leads to problems. Because the regressions that could easily be tested for usually are, that makes new regressions even harder to nail down, which is one of the reasons they’re so hard to fix. My only bit of advice if you’re trying to fix them is to nail down which changeset caused the problem, and investigate every part of that for how it affects other things.
Andy Schmitz
