Prediction of # of bugs in a program?

There are far too many variables to even specify an order of magnitude. It is as likely to be 3 as it is to be 500.

37

Well your max is one bug per line of code. Your min is 0. I'm guessing somewhere between those two numbers. There are far to many variables and the number really doesn't mean anything if you figure it out statistically. All that really matters is that you learn from the bugs you get back and don't make those mistakes in the future if you can help it.

i've made more than 1 bug in 1 line of code

Every program contains at least one bug.
Every program can be reduced by one line.

Therefore, every program can be re-written as one line of code that doesn't work.

All I can say is this:
Be suprised if you only get 10 bugs back. Expect somewhere in the hundreds.

Quote:

Original post by JBourrie Every program contains at least one bug. Every program can be reduced by one line. Therefore, every program can be re-written as one line of code that doesn't work.

My programs never have bugs. I do occasionally have some unexpected features however. [grin]

Seriously though, it's very difficult to guess how many bugs you'll have.

Quote:

Original post by Colin Jeanne Quote: Original post by JBourrie Every program contains at least one bug. Every program can be reduced by one line. Therefore, every program can be re-written as one line of code that doesn't work. My programs never have bugs. I do occasionally have some unexpected features however. [grin] Seriously though, it's very difficult to guess how many bugs you'll have.

I prefer the term "emergent behavior"

If you're a reasonably competent programmer: More than 20, less than 200.

John B

Quote:

Original post by JBourrie I prefer the term "emergent behavior"

LMAO...

Anyway, if you're so worried then you should try hunting for bugs yourself. Personally, I try to integrate debugging into the development stage since it is most often the hardest part of a project. Test as you go and never trust that the user won't do something stupid.

*edit*

Quote:

Original post by JohnBSmall If you're a reasonably competent programmer: More than 20, less than 200. John B

Sure... tell that to Microsoft.

This might help: Cyclomatic Complexity

Quote:

... One better metric was invented by Tom McCabe in, believe it or not, 1976 (Next year, the paper he wrote will be 30 years old and yet, still, many developers have not heard of either the paper or the concept.) He called it cyclomatic complexity, and it is a description of the complexity of the control flow of a program (or a method, in our case). To put it another way, it's a numerical description of the complexity of a flowchart: the more decision boxes in a flowchart, the more complex the control flow. By analyzing many software projects, both before and after the software was released, he showed that the reliability of a program is inversely correlated and the number of errors a program exhibits is directly correlated to its control flow complexity. In other words, the more complex a program is, the less reliable it is and the more errors show up after the program is released. McCabe's research has been confirmed in later years by other researchers. His findings have been extended by additional metrics (such as, the number of local variables coupled with the cyclomatic complexity is a better indicator of a program's reliability), but the CC metric is still an extremely good indicator of how "good" a program is. ...

I am not sure if this is completely accurate but I've heard for the average professional program you can expect to have at least three major bugs per 1000 lines of code. That means you will have about 159 bugs that are "important" bugs. This usually doesn't account for non-detrimental bugs such as little things like, this or that texture doesn't quite look right, or usability issues.

Thanks for the replies.

I was actually quite low in what I thought was acceptable for number of bugs in a beta piece of software.

Brian

Quote:

Original post by T1Oracle Quote: Original post by JohnBSmall If you're a reasonably competent programmer: More than 20, less than 200. John B Sure... tell that to Microsoft.

Microsoft's software is probably more than 50,000 lines of code. I'm also not counting inconsequential bugs (ie, purely cosmetic things, or items which are not bugs but rather things that could be improved.) And then of course there's the issue that there may well be bugs in your software that will never be found. Microsoft's software is used more widely than this beta test will be, I assume. Having said all that, XP seems pretty stable to me - given how complex it must be, I think it stands up pretty well, as does the other MS software that I use.

If the software has reached beta test, then it has presumably undergone some testing during development, and possibly a dedicated in-house testing phase. I see no reason why it shouldn't be possible to write a 50,000 line piece of software and only find a hundred or so individual bugs during beta test*. If it isn't possible, then we (developers) really need to work on our development processes some more.

It's all a moot point anyway. As everyone has said: it's extremely difficult for anyone to predict, and it's certainly impossible for anyone without very detailed knowledge of the project and your programming abilities (your own estimates would likely be far more accurate than ours, or at the least, they'll have a lot more data going into them)

John B

* I see no reason in theory why there shouldn't be fewer - hence the lower value of only 20 - but I'm trying to be at least vaguely realistic here.

Also remember feature requests and bugs that aren't really bugs IE: "Feature X does Y but I want it to also be able to do Z!" and "Feature X does Y but it shouldn't becuase feature W does Y so Feature X should do V" ;).

I am sure that will happen loads :). Good luck, I hope your program is easy to expand!

42. Never more, never less.

And just what is that methods purpose? To keep the morale of QA up?

The answer is simple; one more.

Quote:

Original post by RDragon1 And just what is that methods purpose? To keep the morale of QA up?

Morale in QA is never up...