3 ms·

That's interesting, I've read several papers on a direct positive correlation of LOC to # of bugs. Do you have any papers to back up that assertion that there

by rymith 14y ago

That's interesting, I've read several papers on a direct positive correlation of LOC to # of bugs. Do you have any papers to back up that assertion that there is no correlation. Common sense would dictate that the more places humans can insert an error, the more errors will be inserted.

seanmcdirmid 14y ago
Defect rate depends on a lot of things: the language, the programmer's experience and skill level, the kind of code being written. You have to normalize for those factors before you can even begin to think about correlating LOC to estimating bug counts. Now, take a language like Perl, Scala, or APL, where you can do a lot of things on one line of code; the bug density is obviously going to much higher than Java. Given C++'s lack of much safety (both static and dynamic), defect rates will also be higher there also. Then not all defects are created equal. Can the defect be easily detected via static analysis or unit testing? Those defects will wash out during the dev process, but the time needed to find and fix them has to be considered. We also have to apply more weight to wicked defects that are not easily detected (say memory corruption in C++ that causes bad behavior away from where the defect actually originates). I don't have any papers though I believe this style of thought originates from the 70s (like everything else in our field). There is always the folktale about Simoni: some PM at early MSFT instituted a lines of code metrics to measure and rate programmer productivity. The first week, Simoni wrote down something like -10000 LOC for the amount of code he deleted that week. The PM was pretty silent after that. I'm sure I've got this story completely wrong, but the point is that LOC are a crude and crappy metric in any case.
sp332 14y ago
The papers I've seen show that bugs per line of code go down as class size increases, until about 200 lines of code. But since the code is larger, the total number of bugs goes up in larger classes compared to smaller ones (as you would expect). This might be used as an argument against refactoring code into too-small classes, but I'm pretty sure total code length correlates with total bugs. http://news.ycombinator.com/item?id=3037293 http://news.ycombinator.com/item?id=3037293 Edited to remove dumb generality.
- seanmcdirmid 14y ago
  > I'm pretty sure the only way to minimize bugs is to write less code. Please think about what you are saying. Such an overly broad statement is so easy to shoot down, I'm sure there are plenty of other ways of minimizing bugs. NASA and Boeing have this figured out, for example, although it is incredibly expensive (formal verification, independent redundancy, extensive testing, static analysis, etc...).

by rymith 14y ago

seanmcdirmid 14y ago

Defect rate depends on a lot of things: the language, the programmer's experience and skill level, the kind of code being written. You have to normalize for those factors before you can even begin to think about correlating LOC to estimating bug counts. Now, take a language like Perl, Scala, or APL, where you can do a lot of things on one line of code; the bug density is obviously going to much higher than Java. Given C++'s lack of much safety (both static and dynamic), defect rates will also be higher there also. Then not all defects are created equal. Can the defect be easily detected via static analysis or unit testing? Those defects will wash out during the dev process, but the time needed to find and fix them has to be considered. We also have to apply more weight to wicked defects that are not easily detected (say memory corruption in C++ that causes bad behavior away from where the defect actually originates). I don't have any papers though I believe this style of thought originates from the 70s (like everything else in our field). There is always the folktale about Simoni: some PM at early MSFT instituted a lines of code metrics to measure and rate programmer productivity. The first week, Simoni wrote down something like -10000 LOC for the amount of code he deleted that week. The PM was pretty silent after that. I'm sure I've got this story completely wrong, but the point is that LOC are a crude and crappy metric in any case.

sp332 14y ago

The papers I've seen show that bugs per line of code go down as class size increases, until about 200 lines of code. But since the code is larger, the total number of bugs goes up in larger classes compared to smaller ones (as you would expect). This might be used as an argument against refactoring code into too-small classes, but I'm pretty sure total code length correlates with total bugs. http://news.ycombinator.com/item?id=3037293 http://news.ycombinator.com/item?id=3037293 Edited to remove dumb generality.

seanmcdirmid 14y ago
> I'm pretty sure the only way to minimize bugs is to write less code. Please think about what you are saying. Such an overly broad statement is so easy to shoot down, I'm sure there are plenty of other ways of minimizing bugs. NASA and Boeing have this figured out, for example, although it is incredibly expensive (formal verification, independent redundancy, extensive testing, static analysis, etc...).