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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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
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.