@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!
–
blundersDec 14 '11 at 3:08

2 Answers
2

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.

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.