Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Does the Pareto Principle, that being 20% of the causes are link to 80% of the problems, apply to software bugs, and if so, are there any common patterns of note on average within the 20% of cause?

share|improve this question
    
I hope this stays open - one of the more process management oriented people might even have an answer. –  psr Dec 14 '11 at 0:26
    
I believe at least the first part of this question is discussed in my process/product quality book, but it's at work since a process engineer is borrowing it. –  Thomas Owens Dec 14 '11 at 0:32
    
@Thomas Owens: Misko Hevery has a "Unified Theory of Bugs" which comes close to answering the second part, though the source of the data behind his findings is unclear. He gave a Google Tech Talk on it at the end of 2010, "How to write clean, testable code" - if you're able to find solid research later, please post an answer. Thanks! –  blunders Dec 14 '11 at 3:08
add comment

2 Answers

up vote 3 down vote accepted

Sure, there are plenty of patterns where bugs can emerge. These are a couple of categories I have encountered in my career, but I'm sure there are many others.

Lack of Ownership -> Code Atrophy

If there is module, tool, or library that nobody is responsible for then it will quickly become a bug-farm. If a piece of code has a clear owner, then somebody is on the hook for the code's clarity and overall maintenance. However, if code is allowed to rot then many local-fixes will end up introducing subtle behaviors that will break future clients.

Poor Architecture -> Ignored Requirements

Another pattern which causes bugs to crop up is poor architecture, specifically tight coupling. Poor architecture leads to tightly coupled components that have an unofficial contract between one another. For example, initialize needs to happen in a certain order. This leads to implicit requirements for using code.

A hypothetical example would be: you create a new Servlet for exposing a new webpage. However, that servlet will crash in production. The reason for this is that servlets will work correctly when exposed from http://localhost/ however, in prod they need to be registered with the ServletAuthorizationManager or some other hidden constraint.

share|improve this answer
add comment

Lack of vision : know who the actual end user will be

A surprisingly pattern I have seen emerge in some larger corporation though I feel it can also effect smaller teams too (large corporation here means more a self perceived state of mind of said corporation than it's measurable size).

The fact that system designers and architects do not see the whole picture of how the software is truly utilized. This creates systemic software where some parts of the system is completely ignored in the specs. For example cutting out the people who will configure it for the customers by thinking and designing the system to be configured by the customers themselves. Reality however makes that the system is very complex to configure and install, so much that the training required to perform the job can takes months. Yet persistently they refuse to invest in tools to help mass configuring making the whole process a laborious manual operation.

This runs deeper than lack of tools, documentation, because it is believed to be targeted to end users goes through a long process of revision and styling and great effort is placed in vulgarization. The end result is a document that is still too complex for the end user to use yet because of the lengthy process in creating this doc it is out of date and incomplete making it also useless for the people configuring the system.

This is just an example but it applies to implementation teams, support teams, trainers and many others that, although do not directly participate in the creation of the software, are still an integral part of the system the software is to service.

In short if you build a system for a doctor, it is not necessarily him that will operate ALL the aspects of the software.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.