relation between bugs and compilation time

You may have seen research papers where they come to the conclusion that for every 100 lines of code 1 bug is in it and stuff like that.

Now I've been given this big project where the complete software has to be turned upside turn and in the end it has to behave exactly the same as before.
Now its taken already 3 weeks to get the project even compiled and Im wondering if anybody ever saw some research being done where they relate the duration of a project and/or bugs to getting it compiled.
So if a project takes 1 month to get compiled that you can expect a total duration of 10 months to weed all bugs out or something.

How much source code do you have? 1 month of compilation time is an awful lot of source code - even an old 486 would compile the Linux kernel in a few hours - so I can't quite fathom the amount of code that 1 months worth of code, even on a 486 would be.

Or do you mean that it took a month to produce something that successfully compiles? That probably means that you are writing too much code before you compile it. We're not in the 1970's where you had to schedule your compile work in advance - compile often, writing small pieces of code. Fix the compile errors, then get on with the next step of work.

--
Mats

Quote:

---

1 month of compilation time is an awful lot of source code

---

Eh, I think he meant the other option :)

Did you mean that it took a month to get the project, as you received it, to compile? Or that it took this long after you had modified it?

Quote:

---

Originally Posted by CornedBee

Eh, I think he meant the other option :)

Did you mean that it took a month to get the project, as you received it, to compile? Or that it took this long after you had modified it?

---

yes, it took that time to get it to compile again

And how much changes did you do to the original code? How much code was it?

If it was a lot of code with a lot of interfacing to other code, then I expect a fair bit of time is quite likely.

But I don't think there is any way to directly correlate number of bugs to the time it takes to make the code compile [for example, if you have a "loose" interface that uses all basic types, void pointers and such, you may get it to compile quite quickly - but there will be more runtime errors, whilst a more strict interface will flag up bad parameters, saving the error from being produced in runtime].

--
Mats

Statistical analysis of coding time is an utter fail. Bean counters keep tryign to pin it down, but the fact is you cant draw anything more than teh most general conclusions, i.e. more bugs will generally take longer than fewer bugs. The nature of projects is so different from one to the next that you cant say Project X will take W man months, will have Y major bugs and will cost Z dollars. You can give a gueastimate, which is usually accurate withint +- 50%, but its just as likely to take longer as it it to be done early.

> Now I've been given this big project where the complete software has to be turned upside turn and in the end it has to behave exactly the same as before.
Do you have a good set of tests which tested all the functionality in the old system, and can apply all the same tests to the new system?

Can you verify the thoroughness of your tests (in both cases) using various code coverage tools?

If either is "no", then you've got work to do.

I'm working on something similar. A layer of code our product relies on is getting too serpentine to maintain and extend, so another engineer here rewrote it using more modern techniques. The design is sound, but he never compiled it as he was developing, so there were a lot of syntax problems -- if I remember, over 800 errors in about 5000 lines of code.

It took two weeks to get it to a compilable state. Since then, it's been another two weeks and most of the bugs have been removed (by me). There were nowhere near as many actual bugs as there were syntax errors.

So there's a data point.

Quote:

---

Originally Posted by Salem

Do you have a good set of tests which tested all the functionality in the old system, and can apply all the same tests to the new system?

---

very good point, there is no such thing :( Maybe thats the reason why I have this dreadful feeling hanging over me when working with this code. All testing is done by a test team and experience

But I guess now its too late to create the tests as then you would have to test the tests first :)

will take at least 6 months to get it working again

> But I guess now its too late to create the tests as then you would have to test the tests first
How so, you've still got the old one right?

Quote:

---

Originally Posted by brewbuck

I'm working on something similar. A layer of code our product relies on is getting too serpentine to maintain and extend, so another engineer here rewrote it using more modern techniques. The design is sound, but he never compiled it as he was developing, so there were a lot of syntax problems -- if I remember, over 800 errors in about 5000 lines of code.

It took two weeks to get it to a compilable state. Since then, it's been another two weeks and most of the bugs have been removed (by me). There were nowhere near as many actual bugs as there were syntax errors.

So there's a data point.

---

Was that guy using cocaine?