bugginess of code

[steuben]

i was chasing out something is said in #planeshift a couple of days ago
\"for any code beyond a certain size, it can only be rendered asympotically bug free.\" or atleast words to that effect.

so i came up with this equation

n=c*exp(-t*r)-k
with
n= number of bugs
c= the ratio of total lines of active code to the threshold number of lines. naturally removing comments from the total line count
r= the rate of programming
t= time
k= threshold number of lines

k is purely dependent on the language. as some languages are easy then others

r is a nasty number. it is dependent on the skills of the programmer(s), the documentation level/style of the project etc.

n is handwaved to be zero if the calculation is negative.

the rest are straight forward

give that k and r can be reasonable approximated, and n known it is possible to determine the amount of time required to get n to zero. so for a give code size it is possible to get the code to an arbitarily small number of bugs.

looking at the equation though leads to a rather interesting conclusion. but one that perhaps has been observed in practice.

a small piece of code, ie c not very much larger then k, it is possible to fully debug the code in a reasonable length of time. for example a sub routine out of a larger section of code. it is possible to break a large piece of code into such units. however when reintegrated into a whole the number of bugs is dependent on the total size of the code. even though the individual units themselves are bug free.

any comments.

[defender43]

t, and c can be drastically reduced using Python Scripting Language, and r increases many times fold.

[Uyaem]

defender, you do realise that for t -> 0 and r -> 0 (i.e. \"making it smaller\") the number of bugs, calculated with this formula, actually rises?
Good python ad.

EDIT: steuben, while a mathematical approach to that might be a neat thing for an estimation, I don\'t think you\'ll be able to even closely hit the number of actual bugs. But with a few correction factors, this might be a way to calculate the necessary time to make a program \"run well\". But I think one thing is still missing: Complexity of the code. It is a lot easier to write some sort of data storage office application than it is to make a well-performing game engine that is compatible with all gfx cards. And that\'s the most volatile factor...

[Xordan]

And that formula doesn\'t take into account:

1) How good the programmers are.
2) How much they enjoy coding the program.
3) How much they\'re getting paid.

All of these have quite an affect on the number of bugs.

[steuben]

Uyaem that is the \'k\'. which is depentant on language, use a db based language you get a different k then if you used a c variant.

Xordan that is \'r\'. which is dependant on the nature and composition of the project envirnoment, number and skill of programmers, etc.

[Xordan]

Well you should use a proportional symbol instead of equal. You can\'t possibly use such vague variables for an exact formula. We don\'t even know how the values for each variable are calculated.

[DaveG]

One big factor, possibly the biggest in a project like this, is how many programmers there are and how many edit others\' code.  Many, many, bugs are created when someone has to edit/use code which they did not write, and do not fully understand.  Documentation can only help so much, and side-effects are bound to pop up.

The other thing here that\'s missing, is the fact that bugs are not a simple quantity.  Bugs arise, then are fixed.  You might be able to take a pot-shot at how many would be created, or how many might exist at any one time, but this is also all dependent on how many people are fixing the bugs.  There\'s a trade off here:  you can\'t only fix bugs, but you can\'t only make new code.  So it comes down to a balance (like pretty much everything).

(Btw, if you\'re looking for a conclusion here... tough.    I don\'t really have one.  You can\'t really make an equation about this sort of thing, and a simple exponential isn\'t going to come even close.    The logic here is valid, but isn\'t quantifiable as such.)

[acraig]

There are other variables that you need to count as well.  When considering threads and networking information the possibility for bugs or undefined states increase dramatically.  Often times we work in the \'ideal\' condition with client and server all on one machine.   As a results bugs can arise when we go \'public\' because there are just things that happen we never considered.

[steuben]

*points to the variable r, yet again.*

r is just a placeholder for just about everything that can effect the rate of debugging. and is _highly_ project dependant. client server apps, lower r. highly skilled and motivated programmers raise r. code reuse raises \'r\'. poor project management lowers r. etc.