MozillaZine

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.


#36 remedies for defect problem

by Anon

Thursday December 2nd, 1999 9:58 AM

You are replying to this message

So, to begin the discussion of remedies for this defect problem:

1. The first step toward solving any problem is to acknowledge it. Unfortunately in software this can be the hardest step. Alcoholics are often more rational than programmers. Nuff said.

2. Cut back on the project scope. This is the no-brainer "easy answer." No one likes cutting features but it's always necessary when a project goes out of bounds. In this case, Mozilla includes side projects of questionable importance to the main browser goal, such as an HTML editor and a mail/news reader. Focusing on the main goal would displease those engineers who are working on side projects, and probably cause attrition, but even if fifty percent of them left that would still make the project more manageable logistically and give a resource boost to core components.

3. Lock out new features. Really a subset of 2. This requires management and technical leadership to be able to put their feet down when programmers follow their natural proclivity to write new, cool code instead of fixing the boring old bugs in the existing code.

4. Bug fix incentives. Bug fix bonus programs are easier to do wrong than right; I always think of Dilbert's Wally announcing "I'm gonna code me up a station wagon!" when the PHB announced a simple per-fix payment program. The best way I've seen to structure such a reward is to base the total in the general bonus pool on downward motion of the overall defect line, then incent individual contributors based on their contribution to that downward trend, weighted by severity.

5. Root cause analysis. Find out where the bugs are coming from. What components have what rate of bounced bug fixes, that is, either reported "fixes" that don't work or "fixes" that generate new problems? These components have architectural problems. Concentrate senior technical resources on analyzing those components and on seeing whether their structural problems can be fixed or whether they need to be replaced.

Those are my ideas for ways to address the problem. Others?

Hoping to see Mozilla ship some day, your humble servant, Echinacea Feldercarb