Want a 64 channel, 1 GHz logic analyzer? Take the salary survey and you'll be entered into a drawing to win one at the end of February, 2018.
Volume 2, Number 1 Copyright 1997 TGG June 16, 1997
You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
EDITOR: Jack G. Ganssle, firstname.lastname@example.org
- 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.
Long time readers may know that your editor is a columnist for Embedded Systems Programming and EDN magazines. Both are wonderful publications, and both are tremendously supportive of my wish to publish thoughts about unusual subjects. Neither, though, is really the right venue for the short subjects I generally address in these emailed newsletters.
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 (email@example.com) 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..."