{"id":499,"date":"2011-08-26T12:30:00","date_gmt":"2011-08-26T12:30:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/how-many-bugs-do-you-have-in-your-code.html"},"modified":"2012-10-21T20:05:06","modified_gmt":"2012-10-21T20:05:06","slug":"how-many-bugs-do-you-have-in-your-code","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/08\/how-many-bugs-do-you-have-in-your-code.html","title":{"rendered":"How many bugs do you have in your code?"},"content":{"rendered":"
If you follow Zero Bug Tolerance<\/a> of course you\u2019re not supposed to have any bugs to fix after the code is done. But let\u2019s get real. Is there any way to know how many bugs you’re missing and will have to fix later, and how many bugs you might already have in your code? Are there any industry<\/span> measures of code quality<\/a> that you can use as a starting point? <\/p>\n

For questions like these, the first place I look is one of the books by Capers Jones: arguably the leading expert in all things to do with software development metrics. There\u2019s Applied Software Measurement<\/a>, or Estimating Software Costs<\/a>, or Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies<\/a>. These books offer different views into a fascinating set of data that Capers Jones has collected over decades from thousands of different projects. It\u2019s easy to spend hours getting lost in this data set, and reading through and questioning the findings that he draws from it. <\/p>\n

So what can we learn from Capers Jones about bugs and defect potentials and defect density rates? A lot, actually. <\/p>\n

On average 85% of bugs introduced in design and development are caught before the code is released (this is the average in the US as of 2009). His research shows that this defect removal rate has stayed roughly the same over 20 years, which is disappointing given the advances in tools and methods over that time. <\/p>\n

We introduce 5 bugs per Function Point (Capers Jones is awfully fond of measuring everything by Function Points<\/a>, which are an abstract way of measuring code size), depending on the type of system being built. Web systems are a bit lower surprisingly, at 4 bugs per Function Point; other internal business systems are 5, military systems average around 7. Using backfiring<\/a> (a crude technique to convert function points back into LOC measures) you can equivalence 1 Function Point to about 50-55 lines of Java code<\/a>. <\/p>\n

For the sake of simplicity, let\u2019s use 1 Function Point = 50 LOC, and keep in mind that all of these numbers are really rough, and that using backfiring techniques to translate Function Points to source code statements introduces a probability of error, but it\u2019s a lot easier than trying to think in Function Points. And all I want here is a rough indicator of how much trouble a team might be in.

<\/div> <\/div><\/p>\n

If 85% of bugs are hopefully found and fixed before the code is released, this leaves 0.75 bugs per Function Point unfound (and obviously unfixed) in the code when it gets to production. Which means that for a small application of 1,000 Function Points (50,000 or so lines of Java code), you could expect around 750 defects at release <\/span>. <\/p>\n

And this is only accounting for the bugs that you don\u2019t already know about: a lot of code is released with a list of known bugs that the development team hasn\u2019t had a chance to fix, or doesn\u2019t think is worth fixing, or doesn\u2019t know how to fix. And, this is just your code: it doesn\u2019t account for bugs in the technology stack that the application depends on: the frameworks and application platform, database and messaging middleware, and any open source libraries or COTS that you take advantage of. <\/p>\n

Of these 750+ bugs around 25% will be severity 1 show stoppers \u2013 real production problems that cause something significant to break. <\/p>\n

Ouch \u2013 no wonder most teams will spend a lot of time on support and fixing bugs after releasing a big system. Of course, if you\u2019re building and releasing software incrementally, you\u2019ll find and fix more of these bugs as you go along, but you\u2019ll still be fixing a lot of bugs in production. <\/p>\n

Remember that these are rough averages. And remember (especially the other guys out there), we can\u2019t all be above average, no matter how much we would like to be. For risk management purposes, it might be best to stick with averages, or even consider yourself below the bar. <\/p>\n

Also keep in mind that defect potentials increase with the size of the system \u2013 big apps have more bugs<\/a> on average. Not only is there a higher potential to write buggy code in bigger systems, but as the code base gets bigger and more complex it\u2019s also harder to find and fix bugs. So big systems get released with even more bugs, and really big apps with a lot more bugs. <\/p>\n

All of this gets worse in maintenance<\/span><\/p>\n

In maintenance, the average defect potential for making changes is higher than in development, about 6 bugs per Function Point instead of 5. And the chance of finding and fixing mistakes in your changes is lower (83%). This is all because it\u2019s harder to work with legacy code that you didn\u2019t write and don\u2019t understand all that well. So you should expect to release 1.08 bugs per Function Point when changing code in maintenance, instead of 0.75 bugs per Function Point. <\/p>\n

And maintenance teams still have to deal with the latent bugs in the system, some of which may hide in the code for years, or forever. This includes heisenbugs and ghosts and weird timing issues and concurrency problems that disappear when you try to debug them. On average, 50% of residual latent defects are found each calendar year. The more people using your code, the faster that these bugs will be found. <\/p>\n

Of course, once you find these bugs, you still have to fix them. The average maintenance programmer can be expected to fix around 10 bugs per month \u2013 and maybe implement some small enhancements too. That’s not a great return on investment. <\/p>\n

Then there\u2019s the problem of bug re-injections, or regressions \u2013 when a programmer breaks something accidentally as a side-effect of making a fix. On average, programmers fixing a bug will introduce a new bug 7% of the time \u2013 and this can run as high as 20% for complex, poorly-structured code. Trying to fix these bad fixes is even worse \u2013 programmers trying to fix these mistakes have a 15% chance of still messing up the fix, and a 30% chance of introducing yet another bug as a side effect! It’s better to roll-back the fix and start again. <\/p>\n

Unfortunately, all of this gets worse over time. Unless you are doing a perfect job of refactoring and continuously simplifying the code, you can expect code complexity to increase an average of between 1% and 3% per year. And most systems get bigger over time, as you add more features and copy-and-paste code (of course you don’t do that): the code base for a system under maintenance increases between 5-10% per year. As the code gets bigger and more complex, the chance for more bugs also increases each year. <\/p>\n

But what if we\u2019re not average? What if we\u2019re best in class?<\/span><\/p>\n

What if you are doing an almost perfect job, if you are truly best in class? Capers Jones finds that best in class teams create half as many bugs as average teams (2.5 or fewer defects per Function Point instead of 5), and they find and fix 95% or more of these bugs before the code is released. That sounds impressive – it means only 0.125 bugs per Function Point. But for a 50,000 LOC system, that\u2019s still somewhere around 125 bugs on delivery. <\/p>\n

And as for zero bugs? In his analysis of 13,000 projects over a period of more than 40 years, there were 2 projects with no defects reported within a year of release. So you can aspire to it. But don\u2019t depend on it.<\/p>\n

Reference: <\/i><\/strong>Bugs and Numbers: How many bugs do you have in your code?<\/a> from our JCG partner<\/a> Jim Bird at the Building Real Software blog<\/a>.<\/p>\n

Related Articles :<\/i><\/strong><\/div>\n