Volume 2, Number 1 Copyright 1997 TGG June 16, 1997
You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
EDITOR: Jack G. Ganssle, email@example.com
- Editor's Note
- Tracking Bugs
- Thought for the Week
- About The Embedded Muse
In Embedded Update issue #49 I announced my departure from Softaid. Now that that has come to pass Iíd like to ask for your indulgence for a quick explanation of where this newsletter is going.
As Softaid will probably continue the Embedded Update, I feel itís inappropriate to use that forum for my own rants and ravings. Therefore, Iíve started a new newsletter, of which this is the first issue. Note the new name - ďThe Embedded MuseĒ - which better reflects my intentions.
With Softaidís permission Iím using the Embedded Updateís list of 3000+ addressees as a subscriber base for this list. Donít want to get these from me? No sweat - just send me (firstname.lastname@example.org) an email asking to get off the list and Iíll take care of it.
I donít believe in making a big fuss about bugs when youíre developing a product. Fix them as you find them; maintain a zero-length bug list at all times so youíre not faced with a swamp of angry and nasty problems at the ďendĒ of a project.
That said, once the product hits the market things change. Itís unrealistic and perhaps unwise to fix post-release bugs as soon as they are discovered. New hardware and software releases are quite expensive, despite technologies like flash that permit in-circuit reprogramming of software and PLDs.
It is indeed necessary to track and manage bugs after release. Far too many outfits use nothing more than a poorly-organized file folder filled with random scraps of paper noting bugs as they get reported. Without a consistent form (at least!) youíre bound to forget to record critical bug info: who reported it, under what conditions it occurs, and the like.
Bugs reflect the productís quality, and so perhaps represent the most important post-release technology management issue. Itís unforgivable to either lose bug information or to fix a bug but neglect the customer who reported it. Further, bug management - or ďdefect trackingĒ as itís more commonly called - sheds light on the development process itself.
You need tools to help manage the inevitable bugs. Whether itís a carefully managed three ring binder of bug reports, a custom database application, or a commercial product, do come up with a system for dealing efficiently with these problems.
I recommend buying instead of inventing a system. Two commercial defect tracking products are Bugbase from Archimedes (http://www.archimedesinc.com/bugbase.htm) and Visual Intercept from Elsitech (http://www.elsitech.com).
Thought for the Week
"General Perception Fault - Reality Terminated..."