How many lines of code do you average per bug?

Question

Hi,

Our team had a bad session with the management today regarding the total number of functional bugs that were coming up in our code.

As for me, I have written around 6 K lines of code for this project and I am personally responsible for 4 functional bugs and 8 usability bugs (inconsistent CSS, page flashing on clicking a button, validation message spread accross two lines).

Is my average lines of code/bug too high? What's your average? Working on a SharePoint project with .NET 3.5.

Kind regards,

Answer 1

Unfortunately... 1

EDIT: Ok, now I'll put something useful here :)

As a Development Manager, I was not concerned with lines per bug, but rather the types of bugs and the level of the developer. Also, lots of lines of code worries me, and I think I would be more concerned if any of my devs wrote 1k lines of code in a day (or even in a couple of days).

I can appreciate the concerns of your management team, however, as bugs really don't look good to the higher-ups, or the client. What I would suggest is that you (or they) develop a process of eliminating these kinds of bugs.

Example: Bob the developer (who is pretty new) just wrote the 'update customer' function. The method works fine, and Bob even validated that the supplied customer ID is good... but Bob forgot to check if the current user has the permissions to edit that customer.

As Bob is new, I expect this bug, and use this as a learning experience (not by bashing him). During our weekly meeting/code review, we discuss this bug, and others like it.

Answer 2

I don't think this question makes sense!

More Lines Of Code DOES NOT EQUAL Good Code

Otherwise I could write 10,000 LOC with 10 bugs and by your statistics that would be better than 100 LOC with 1 bug.

If they both do the same thing though, I'd go for the latter as it has got to be more maintainable and easier to fix!

Answer 3

Personal blame is never a good metric. I don't understand the point of these states though, I might do something in isolation and so might you, put our stuff together and we have a bug. Whose fault is that?

Answer 4

It's a terrible metric for measuring anything because bugs can vary in severity, scope, complexity and can be subjective, never mind line counting being absurd, but as a very vague measure to build expectation I have seen (but cannot cite sadly) that a ratio of 1:100 is "average". That seems high to me, but I believe it was based on input data from a large number of SourceForge projects AND anonymous blue chips.

Answer 5

We had a project > 250K LOC and had around 20 issues per 1K LOC as far as we could measure over about 14 months development time.

Since production deploy issues have dropped to less than 1 per 1K LOC but this seems to be as a result of less pressure on the analysts and there is less churn in the requirements.

Hope that helps :)

Answer 6

I wouldn't say it's high. But I would say it's a poor metric for management to use to measure performance since it is easily rigged. All one needs to do is write excessive lines of code in order to improve one's statistic.

Instead of:

if(condition1 && condition2 && condition3 && condition4)
{
 //do something
}

You'll get this appearing in your developer's code:

if(condition1)
{
   if(condition2)
   {
    if(condition3)
    {
      if(condition4)
      {
       //do something
      }
    }
   }
}

Answer 7

Since "bug" is subjective, the conversation is merely finger-pointing.

"But we have 'functional' and 'usability'," folks say, "that's not subjective."

Actually, it is still subjective.

1. The application crashes. Okay. That's objective.

2. The application doesn't do something specified. Usually this is objective, but only if the specification is reasonably clear.

3. The application doesn't do something, but the specification is unclear or omits it. Bug? Since, the specification is murky, or doesn't address it, it's a specification problem, not your bug.

4. The application works, but users make mistakes. What's that? Bad design? Who's bug is that? What if you have a correct implementation, but it's not usable?

5. The application is fluky. Is that your problem, or is it a bug in Internet Explorer? What if it's on a "bug list" for Internet Explorer? Does that absolve you? What if it's a problem in the database? What if the API documentation is wrong, and your "bug" is right per the documentation, but still doesn't actually work as expected?

Answer 8

You can have your code on time, or bug free. I probably write code with multiple bugs per line, but then I have backspace and a static compiler for cleaning things up. Then it is just a matter of looking, with the number of bugs falling asymptotically as time spent on testing approaches infinity.

If you look hard enough eventually you will find something to fix, until you realized the code you wrote needs to be completely redone, refactored and poof, the code is now 100% buggy code.

A single metric isn't enough to evaluate quality of code or workmanship. Give me everything that can be measured about your code then we can draw an opinion that isn't based in a likely arbitrary number.

I'd think immeasurable like "how complex is the problem your trying to solve," "how happy is the customer," are the remaining issues something "we can live with". And bug free code is a myth that lives only exists only in the mind of project managers with a perfectionist personality disorder.

Answer 9

How would my measure help you?

Maybe you can compile an average of bugs/LOC, and convince your management that you aren't such a bad bunch of coers after all. But you would still use an invalid measurement of functionality.

A programmer is not a typist, and a bug is not (just) a typo. Either your management learns that, or you have to learn to live with mediocre management.

However, that's no excuse for you. The question is: Why did these bugs happen? When were they found? Is your process in need of improvement?

That's the thing management needs to tackle - not invent arbitrary measures. However, you might be among the masses that have to live with non-managing management. In that case, you can either throw your hands in the air, or tackle the problem yourself.

Relevant reading: Joels Econ 101 management - I don't agree with all of that analysis, but it's the canonical article that springs to mind about management that doesn't manage.

Joels Performance measurements don't work (I remember many articles out there, some more to the point, but my google foo seems in is in economode right now)

Answer 10

I have documentation somewhere (looks in archive folders but can't find) stating that a developer usually averages one bug per function point. It's not how many lines of code created, it's how many things were touched.

Examples of function points would be a webpage that has CSS, HTML, JavaScript, PHP, and MYSQL.

If there is a simple project that requires the creation all five function points, then a seasoned developer will average five bugs. Obviously, they will hopefully be found and fixed, but initially there will be an average of five bugs.

Answer 11

Here's a little tip, never focus on these metrics at the meeting, focus on what you're doing to resolve the problems. Bugs happen, it's a fact of life, but as the project matures, your unit and system testing capabilities should be growing such that functional bugs get weirder and rarer. As long as you can show marked improvement, management will give you the benefit of the doubt.

So the real question you should be asking yourself is "How and why did these bugs get through our testing?" and then "How can we catch such bugs in the future?"

If you can reasonably answer those two questions in a meeting with management, they'll leave happy. For bonus points, start working on some of those things. The best way to impress management is to let them think they came up with an idea, then drop the line that you're already working on it. They'll feel smart, you look prescient and everybody wins.

Answer 12

I don't think this metric is helpful. An inefficient coder can create far more lines of code without adding to the usefulness.

Or, to put it another way: I could improve my lines/bug ratio by adding lines that don't do anything useful, by violating the DRY principle, or by using inefficient algorithms. Even if I don't introduce any new bugs by doing these things, I'm likely to create problems for whoever needs to maintain this code later, and cause them to introduce more bugs. From a bean counter's perspective, I look better and the next person looks worse, but who is really to blame for the later bugs?

Answer 13

for LoC:Bugs -

1:1 or less is a good ratio, for noobs

but i have seen it go as high as 1:5 for careless noobs ;-)

in a large system from several years ago where things like this were carefully measured, i had 5000:1 (library and framework code), the average was 200:1 (application code); the in-house prima donna had 50:1 (utility code).

I carefully designed everything in advance including automated tests (because the library and framework were complicated!), the average guys banged out app code and tested manually, and the prima donna coded like the wind without designing anything first. Each section was around 50KLoC when completed.

i got laid off, the prima donna went to work for Microsoft, and the average guys got promoted!

Answer 14

It depends on the code. It's a lot easier to write some code than others. I have a video game I made that's around 15k lines of C, and it is remarkably stable and has a very low rate of bugs, despite some complexity. Professionally, I also work on some linux driver code, considerably fewer lines than 15k though. It is a lot harder to write bug free driver code for a few reason: the code has to fit into a much larger, more complex framework (the kernel) and the code has to also work with a lot of different kernels that various distributions ship. So, for my stupid little video game it was relatively easy to write 15k lines of C, almost completely bug free, but very hard to write, say, 500 lines of driver code bug free (as I've experienced painfully this last month.)

So, it depends. There's no simple answer to this.