RedHat to Invest in Mozilla

Monday November 29th, 1999

Gerbil writes, "Our 'beloved' ZDnet has another Mozilla-related article, and it's actually positive this time! It states that Red Hat plans on investing money and resources in Mozilla. After all, Red Hat does use a version of Bugzilla for their bug tracking. Very interesting."

We'd be remiss if we didn't mention Chris Blizzard of RedHat, whose contributions to the Mozilla project have been invaluable.

#26 ever-increasing defects: a serious problem

by Anon

Wednesday December 1st, 1999 11:49 AM

You are replying to this message

This is Echinacea Feldercarb again, the original bug links poster.

I find it rather surprising that people would not consider a 5K bug load and a near-monotonic upward defect curve out of hand for an application at any stage of development.

Logistically, managing a 5K bug database would exceed the capabilities of any quality or engineering organization I've worked with. Consider tasks like regression and duplicate screening. They grow linearly with the number of bugs, and are critical path items that control the performance of the whole quality effort.

Size is no excuse. The risk of a bug increases as program complexity increases -- the only way to have a complex software system work together properly is if the modules are solid. Integrating flaky modules becomes harder and harder as the system grows, until finally integration cycles start to undergo major failures, and ultimately the project is canceled (see Copland). More complex systems demand better quality engineering from the start or their failure risk grows exponentially with their size.

Development stage is no excuse. There's never an excuse for submitting a bug-ridden component. You can't produce quality software by just throwing code at the wall and seeing what sticks, even in the name of "adding critical features". Each bug in a component presents a risk that it will expose a major architectural problem in the component requiring it to be rewritten. If the component isn't solid, you don't know whether it can be made suitable for shipment later in the development cycle. For a single component of a large system to have hundreds of bugs makes it virtually certain that the component will need to be replaced. For the bugs not to get addressed until alpha or beta means that you will be replacing major components late in the development cycle, which is essentially resetting the software to a pre-alpha stage. This is a recipe for never shipping.

Given that the problems with this bug load and the ever-escalating defect line are obvious to anyone who has been through the process of releasing large software products, the question is what can be done? I have some ideas but I'd prefer to hear others's first.