The sordid life of software bugs, exposed!

The sordid life of software bugs, exposed! is a very interesting look into the software bug process within Microsoft.  While this is about another MS product my impression is that this a very common approach within Microsoft.   If you are going to report a bug to Microsoft it helps to have an exact repro scenario including an example file if appropriate and why you think it’s important to a lot of people that Microsoft should fix it ASAP versus in the next Service Pack versus never.

I do something similar but vastly simplified in my shrink wrap program the Granite Fleet Manager.   With a few minor exceptions.  Every time I come across a bug or problem that I can’t fix and test in five minutes it usually gets entered into an Access database.    Now if the bug or problem in a feature that I’m working on and I’m going to get to it in a day or two then I’ll enter it in my active OneNote page I use as a notepad for that particular feature.  Then I cross it off once I’ve done using the strikethrough font capability.  (I’ve added the strikethrough button to my OneNote Toolbar.)  

I frequently find that as I go through my list of outstanding bugs that I’ve already done several but had forgotten they were in my list.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>