Confessions Of An Angry Programmer

Recently, after doing the keynote session about code quality at a conference in Denver, I received a comment from one of the attendees. He said my session was “too much angry coder”. After receiving many great comments about the session, this one took me by surprise. I thought about it for awhile and commented back, via Twitter…



My comment is so true, most of the in-production code that I see is severely lacking in code quality, even the basics. Many of the apps I use are also lacking when it comes to code quality. Since I feel so passionately about this, the theme for all my code conference sessions is and will be for the foreseeable future…

Improving Code Quality… One Developer At A Time™

Several years ago, I decide to just focus on the developer, to try to improve code quality. My goal every time I do a conference session is to motivate just one of the attendees to go back to their team and make quality an important feature of their software projects.

Need Proof?

In a few of my conference sessions, I show the following numbers from a in-production application, they are pretty shocking.

• Critical Error Violations = 4
• Error Violations = 741
• Critical Warning Violations = 41
• Warning Violations = 22,316
• Information Violations = 1,100

The solution has 333,606 lines of code… that is a violation every 13.78 lines of code!

The Breakdown

Here is the breakdown by violation type:

• NET = 28
• NET Security = 46
• Code Style = 1,100
• Code Design = 1,254
• Exception Handling Design = 458
• Exception Handing Usage = 221
• General = 391
• Globalization = 5,378
• Interoperability = 2
• Maintainable = 73
• Naming = 8,074
• Performance = 1,180
• Security = 49
• Spelling = 5,759
• Usage = 189

On top of that, the solution has:

• Over 65K possible cloned lines of code.
• Average maintainability index of 77. The goal is to have an index of 100.
• Total cyclomatic complexity of 95K.
• Average inheritance depth of 1.7.
• Average class coupling of 5.76.

I would like to talk about the cyclomatic complexity number. In the end, that number is the minimum number of unit tests that need to be written just to test encapsulation (the first pillar of Object Oriented Programming)! This project has only 1,800 unit tests (that takes over an hour to run) with none of them testing encapsulation! This is a recipe for disaster or what I like to say, it is a house of cards. All house of cards will eventually fall down.

Unfortunately, these numbers and worse are what I see in most code that I analyze. The trick to not getting numbers like this is to either not do them in the first place or fix them while you are coding. I doubt that if you went to your manager and said that the app has over 24K violations, he or she would give you the time to go and fix them. The numbers above are down from when I first got a hold of the code since I spent over a year fixing the most important ones!

How to Learn Good Code Quality Practices