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.

#25 RE: 5k open bugs sucks

by Anon

Wednesday December 1st, 1999 11:28 AM

You are replying to this message


Certainly. I've been involved in 2 projects in the past year. The first project was an intranet application that would allow different internal groups to talk to each other about project specfications. Anyways, the functionality is not that important, what is important is that there were 2 major sources of 'bugs' that were found in our application. The first source was from the testing group about actual bugs in the code modules that we were wrighting. To our development team's credit, the bug count was very low because the modules' functionality were clearly defined and thus easily tested during unit testing. However, the testers who seemed to have nothing to do because the code was nice and tight, had to fill their time up with trying to improve the system's design. They would file 20 RFEs for each bug they found in the system. Sometimes a weekly meeting would just be all RFEs. This, my friends, is what we call 'scope creep' when the testers come in and want to make a better mousetrap that goes beyond the origional conception of what the application was supposed to do.

I am claiming that the increase in 'bug count' (which includes new RFEs) is a bad thing because it's indicitive of either bad unit testing (which I doubt, most coders will make sure that the code does the operation properly before checking it in to source control), or from bad design (which is likely the case, if people feel that they need to submit hoardes of RFEs to improve on the origional design). This increase in bugs/RFEs is certainly a bad thing for getting the browser out the door if they haven't even FROZEN the codebase from future enhancements! There is no WAY they are going to be getting the browser out the door by 1q2000 if they haven't frozen the features from the browser by now!

In anycase, my most recent project has taken extra care on designing the application components very carefully to reduce the likelyhood of RFEs, and also clearly defining modules' functionality makes it easy to test them. This is just my experience.

Tell me, what has your experience been in projects that have a open functionality baselines? Did you find that you could never seem to please your client because they always wanted something different from day to day? I have, and my recommendation is that you get the needs and requirements from them completely agreed apon (signed off on) before you even begin writing software design specs. It may take longer to even begin the design phase, but it will save time in the long run.

Consider this: What would have been the result if the Mozilla team took an extra 2 to 3 months evaluating what it is going to take to use the old code base instead of spendinig 12 months working with the old code base? My feeing is that after 3 months of evaluation, the would have come to the same conclusion that they did after 12 months of physical labor: They had to start over from scratch. Moral: look before you leap, even if it means looking for a long long time.