[dev] Bug handling survey - 80:20 rule

[Gunes Koru]

Hi all contributors of Horde,

As you might have heard, I am conducting a bug handling survey on:

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

So far, we have received answers from the developers, testers, defects
fixers, and project managers in KDE, GNOME, Apache, OpenOffice, Mozilla,
and other projects/sub-projects. Even though, we have not asked any names
or e-mails, some of you have left their contact information and expressed
their willingness for further cooperation in this direction. Thanks for
your interest so far.

If you have not done so, we would appreciate it, if you could fill out
this survey since statistically more and more meaningful interpretations
can be made as your participation increases.  It is a short survey which
consists of three sections that can be filled at once or different
sessions. Many of the questions in the survey were put there purposefully,
and they will make you think about how they apply to Horde project.  You   
will find them very interesting. One more time, this is a research
project,which has many potential implications. This is NOT anything like a
spam, it has no commercial nature and it is aiming to contribute
to Horde just like any other e-mail. We are very "dedicated" to this research,
whose only and only purpose is looking for ways of increasing
the quality of open source products. We apologize in advance if
you receive duplicates of this e-mail.

80:20 rule, which is the subject of this e-mail is a well observed
phenomenon, in many of the large scale software products. These products
were produced by IT, Telecom companies, even by NASA. They were developed
following different methodologies, they were written in different
languages, and the application domain or problems they solve were
different. However, 80:20 rule was still observed. This means that you
might be developing desktop applications, office software, compiler,  
kernel, http server, or whatever, most likely you will make a similar  
observation your project. I included two references at the bottom about
it.  Both of them are very easy to follow and informative. Also, they are
very recent references.

The numbers in 80:20 rule are percentages but not of the same quantity.
80% here represents 80% of the "target risk", which might be defects,  
rework, effort, etc. So, you want to reduce them. 20% represents the     
contributor. You might want to name 20% as modules, component, packages,
for the product if you will. A great deal of your goal in a project lies
in this 80%. And the observations tell us that this 80% target risk stems
from 20% of your modules, or components. If you could only identify this 
20% part in what you develop, you would make substantial improvements in 
quality. The identification techniques could be a subject of another time.
But, now, why is this important? Because, some projects never get to a
desired level of quality, they can not meet their schedule. People code
it, patch it, code it, patch it.. After some time users may loose trust,
it may become something which is not manageable any more. So even though,
the efforts are made by volunteer programmers, it is sad to see that
potential is not used fully. Because these efforts could make even greater
contribution to free software and they could end the software monopoly out
there more quickly.

I am one of those who observes the high amount of traffic in developers
lists. This is huge. Everybody looks at one thing, sees it from a
different point of view, designs are evaluated, code is tested, fixed,
etc. Collaborating, sharing bring many advantages. There is big
potential. I can easily tell that in many cases the communities are much
larger than many software teams in the industry. So, how come the
commercial software can still compete with open source products. One of
the reasons is that they have been applying these techniques for years.
Now think about the advantages of risk identification techniques and the
advantages of open source development combined. Wouldn't it be great? This
is where we see the tremendous opportunity.

As concluding this e-mail, I repeat my invitation one more time. Please
visit:

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

today/this weekend and help us in this research. If you want to see or
remember my previous invitations, they are at the same address. By the
way, if you have already completed it and want to change your answers
(some did ask this issue) please contact me, we need to identify your
unique entry and change it, please do not complete it twice. Thanks for
your support so far. Please contact me for any question you might have.
 
 Gunes

References:

1) Barry Boehm, and Victor R. Basili, "Software defect reduction: Top 10
list", IEEE Computer Magazine, Vol. 34, No.1, pp: 135-137, January 2001.

2) Jeff Tian, "Risk identification techniques for defect reduction and
quality improvement", Software Quality Professional, 2(2):32-41, Mar 2000.
  

--
***************************************************************************

A. Gunes Koru

Research Assistant, Ph.D. Student

Southern Methodist University
Computer Science and Engineering Department
6425 North Ownby Drive
Science and Information Building Room 317
Dallas, TX 75205


Home: 214 691 5633
Work: 214 768 2005
Cell: 214 893 7311
http://www.seas.smu.edu/~gkoru
Email: gkoru@engr.smu.edu

***************************************************************************