Thread: relation between bugs and compilation time

  1. #1
    Registered User
    Join Date
    Jan 2007
    Posts
    330

    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.

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    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?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #4
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    Quote Originally Posted by CornedBee View Post
    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

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    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.

  7. #7
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > 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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  8. #8
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #9
    Registered User
    Join Date
    Jan 2007
    Posts
    330
    Quote Originally Posted by Salem View Post
    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

  10. #10
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > 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?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  11. #11
    Hacker MeTh0Dz's Avatar
    Join Date
    Oct 2008
    Posts
    111
    Quote Originally Posted by brewbuck View Post
    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?

Popular pages Recent additions subscribe to a feed