But wait there's more: I also guarantee that your total over bugs found after release will decrease by at least 20% for the same period...
But wait there's more: I also guarantee that these techniques are so incremental that you will not notice them affecting your schedules directly.
Here are the two techniques:
- Assertions
- Root Cause analysis
Now I know you are about to say that these are not new. I agree they are not but most teams do not employ these easy techniques.
Assertions are an easy way for your code to find it's own problems before your customer find them symptomatically. I would much rather have a message be emitted during testing or deployment that detects an issue than having data corrupted or having a blue screen event.
You can do this incrementally by saying that no bug fix or new feature can be checked in without all changed methods containing assertions. Assertions should test three things: input, output and state. Never assume anything is correct. Input and output assertions are pretty obvious but there are some places in the code where the program is in a unique position to verify the consistency of internal state. All three will not only help insure quality but also give you a leg up when you change your program's assumptions.
Each team must decide what mechanism to use for assertions. The assertions should be light weight and provide enough data when they are triggered so that developers can easily debug the problem. Most assertions can be active all of the time and should be. There are times in critical sections of code where assertion can greatly impact performance. In these cases, you may have to employ other techniques like turning on assertions during testing only and checking result around the performance-sensitive section at a place where the assertions will have less impact.
Because this only affects modified or new code, the incremental cost should not be great. Often assertions can be inserted in minutes per method.
The second technique is really a change to process around bug fixes. If you don't measure and analyze your bugs it is hard to avoid them in the future.
Root cause is easy to do. Don't allow anyone to close a bug without inserting a root cause. Have a fixed number of choice for why the failure occurred (e.g. requirements, design, coding, testing, deployment, other).
Once a month conduct a mortality conference where you review a rollup of causes and go through a representative sample of the bugs. This requires that someone do some statistical analysis to prepare for the meeting to identify frequent causes and commonalities for those bugs.
The next step is to establish changes that will stop those problems from occurring again. This may result in new processes or work.
The act of doing the root cause work has little overhead. As I carefully said above, this will not directly impact your schedules in a direct way. Clearly you may identify process changes or projects to address the root causes and take enough effort that might impact resources.
If you take the statistics, do the work and don't see the impact I guaranteed above, I will provide a free day of consulting to work with you to figure out how to achieve those results.
More later ...
