On the O'Reilly ONLamp.com website today, there's a new article posted that several developers (we all know the type) could probably stand to read. It's Part 1 in the "How to Decide What Bugs to Fix When" series.

Here is the golden rule of organizing bugs: fix bugs in the order most likely to result in success. Sounds obvious, right?

Wrong.

I'd bet that more than half of the buggy and unreliable software you've ever used was that way not because the developers didn't have time to make it better; they simply fixed the wrong bugs. Wanting to fix the right bugs and knowing how to do it are two different things.

They give ten ways not to decide which bugs to fix (including "Fix only the bugs that annoy your CEO" and "Put bugs in alphabetical order...") and move into a "Level 1" explaination of where to *really* start. Level 1 is defined as a "First Aid" kind of look at your application, most important first - stop the bleeding, make the patient comfortable.

From there, the application heads to triage, organizing the bugs so that you can manage and treat the ones that could cause the worst damage. From there, they get into Level 2 - making your "piles" of problems smarter. This consists of breaking down the Level 1 issues into smaller groups based on the severity within them.

Keep an eye out for Part 2 in this series where they get into Levels 3 and 4, and cover some FAQs along with providing some resources and references on the topic...