Software defects generally fall into two primary classifications: defects that represent functional misses of a new implementation, or defects that are regressions in the behaviour of the system due to some change. This paper discusses a major reduction in the Time-To-Fix for regressions. In a previous role I lead a team of engineers in implementing this system.
To improve the Time-To-Fix, it was ultimately determined that we needed to resolve two problems that accounted for the majority of the time developers spent dealing with regressions:
- Reduce effort to isolate the regression. Early effort on bug analysis can be greatly accelerated if the guess-work on which change causes the regression is removed. Using bisection provides an absolute level of confidence of the regression trigger. There is no guessing or supposition. I have written on the use of bisection in preference of code diving in this blog post.
- Ensure that the regression goes to the correct team the first time. Reduction of the bouncing around of the defect report is achieved by identifying the engineer who regressed the issue and ensuring that it is fixed by that person or team. In particular breaking the attempt to reproduce, debug, re-queue cycle prevents days of wasted engineering time.
We implemented and deployed the system described between 2008 and 2010. Read on for more information.
Continue reading “Using Regression Isolation to Decimate Bug Time-to-Fix”
As developers we deal with regressions on a regular basis. Regressions are changes that are introduced to a system that causes a potentially unwanted change in behaviour. Engineers, being wired the way they are have a tendency to want to fix first, understand later (or understand as part of the fix). In a large number of cases however, it is considerably more effective to isolate and understand the cause of the regression before even diving into the code to fix it.
This is a continuation of a series of blog postings I am making on regression isolation and bisection, the first of which was “A Visual Primer on Regression Isolation via Bisection”. If bisection and regressions are terms that you don’t solidly understand, I strongly suggest you read the primer.
Continue reading “Regression Isolation vs Code Diving”
Identifying regressions via bisection is one of those software debugging techniques that I find under utilized and under appreciated in the software industry. Bisection can be used to isolate changes in anything from BIOS updates to software updates to source code changes. This article provides a backgrounder on what bisection is, and how it is useful in identifying points where a regression has been introduced.
This is the first in a set of three posts covering regressions.
Continue reading “A Visual Primer on Regression Isolation via Bisection”