Causes of Bugs

You are probably writing “Bug-Free” code right? I also don’t. Really sad…
I do want to, our customers want that. For that reason I created a statistic in the projects I worked in, to find out which are the most usual causes of bugs. The poll below already contains the results of it. If you solve a Bug, please come back here and fill out this poll!

I categorized it based on the actions a developer made when fixing the bug. Be careful when filling the poll as it is affecting the results heavily. If you don’t understand something from the next poll, read the explanation carefully after it. “Process and Concept” problems are uncovered, please read the explanation to know, what I categorized as such.


You can select one or more of the categories above or suggest a new one as a comment. I’m mainly interested in the actions you’ve made when fixing the bug – and of course it could be more of the above ones. I’ll try to explain some of the categories, if you have further questions please comment on this blog.

  • If I’ve fixed names of variables, classes or methods I’ve selected the Wrong Naming category
  • When I needed to reduce the nesting of the “if” statements to understand what the code is about i checked the Reduce nesting option.
  • Removing a duplicate for fixing a bug resulted in a point for the Code duplication
  • If I’ve reduced the size of a class or method by extracting a class or method I’ve increased at the Too long class or method category.
  • Adding an argument check or a null reference check ended with a selection of the category: Argument check
  • If needed to make a big refactoring including of a class based on its dependencies (like too many injected constructor parameters), I’ve increased at the Reduce dependent and depending types. Read further here.
  • The cohesion is a bigger topic. To fix bugs in this way the cohesion was increased to a higher level (to functional – preferably). Simply said: it is about grouping of modules more semantically. If I’ve grouped methods or fields of a class differently (with only slight changes to them), or moved classes of a namespace into other namespaces, then I’ve increased the votes here. If you want to read further check this Wikipedia site.
  • When programming object-oriented we should follow the SOLID principles. If one didn’t completely do that and I fixed it accordingly, I’ve voted to one of these categories.
  • If a bug came over and over as a regression bug, I’ve introduced a unit-test for it. In fact I try to add a unit test for every bug I need to fix as I find those unit tests the most useful. Anyway, in these cases I’ve selected the corresponding category

The Story

Few years ago I started to try to increase my coding quality by applying static code analysis tools like Microsoft Code Analysis and NDepend. Unfortunately not every project size can afford to have NDepend applied to it. I’ve read the clean code book. Applied further design patterns. Tested even heavier. Added more unit tests reaching high coverage. Started to develop test driven. Applied better architecture and so on…
I’ve collected a lot of weapons against bugs. Not only technical but also interpersonal skills. In fact I’m aware, that these are the most usual causes of bugs and problems with the software. In my last measurement it was around 50%. This is however not the scope of this post – I don’t want to talk about “Process and Concept” problems or noises in the communication starting from the customer along the way to the developers – this should be the topic of requirement engineering and other software development methodologies. How did I separate this from the above categories? I said to myself, that if during the solution of the bug, “tons” of files were changed, or a “lot” of new code was written, then I categorized it as a concept bug. But as I said already, this is out of the scope of this post. What I want to cover is the following question.

Which development mistakes lead more often to bugs?

The poll above doesn’t give you an answer to that. It just tells you, what types of behaviors get fixed more often. For example the amount of bug fixes containing the removal of duplicated code doesn’t point out the bugs, where it wasn’t recognized as a source of it or where the solution of the problem was not to remove the duplicate. Still I believe, this gives you a good hint, where to give more focus, for that reason, it is part of my definition of done.

Is this question to be asked at all? We should do everything correctly according to every rules of the development, right? I guess in many cases it is not possible – in time, in budget. Probably most of the developers met already the “big ball of mud” styled worse “spaghetti” code ever. I did it many times. Many times I wrote it myself – sad again, but my “past me” didn’t know what my “future me” can write better. Still we wanted to satisfy the customer needs, many times successfully.
I don’t know which categorization is the best related to this question. I created this one when I’ve been working in a really high quality web application. I based on the check-ins related to the bugs (using Team Foundation Server) and look at what actions are taken when fixing it. I’ve created these categories as a starting point and I hope you will be happy to contribute and see the results.


About Tamas Nemeth

Husband and proud father of two daughters in Nürnberg. I'm working as a Senior Software Developer and an enthusiastic Clean-Coder. I spend most of my free time with my family (playing, hiking, etc...). I also play table-tennis and badminton sometimes...
This entry was posted in Technical Interest and tagged , , , , , , , . Bookmark the permalink.

2 Responses to Causes of Bugs

  1. Peto Zsolt says:

    Hi Tamas,
    What do you think about such bugs which are in reality very small changes in the code (like a missing if clause or other 1 line change) but contain a large number of other enhancements, for example when the old code was totally refactored. I was wondering what to do when the actual cause of the bug was not fixed by a lets say “code duplication” removal, but this refactoring was also done together with the fix, can we include it in your statistic?

    • Tamas Nemeth says:

      Hi Zsolt,
      good question. The refactorings part of the change count to the statistics. You can (and should) select multiple categories, when doing refactorings accordingly. The small code change part of the whole doesn’t have an own category. So having an example based on your comment as follows:
      – Removing a code duplication
      – Reducing if nesting
      – Adding a line of code
      The following categories are to be selected: Reduce nesting, Code duplication.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s