Jas, regarding:
<<
c) Comparing Matridigm's MAP 2000 to other automated (same class)tools..THERE IS ABSOLUTELY NO COMPARISON .Let me paraphrase Mr. Chait...Matridigm's product returns a million lines of converted code with 0-1-2 bugs/million lines. Other similar tools have '10,000-30,000 BUGS/MILLION LINES OF CODE. WHY IS IT THAT NOBODY HAS SAID A WORD ABOUT THIS COMMENT???
>>
My understanding of this was that they were being somewhat misleading in their example. I heard them say that:
A) Their date remediation tool introduces 0, 1 or 2 bugs per million lines of code.
B) Many commercial software packages in widespread use today have tens of thousands of bugs per million lines of code.
I *think* you understood them to be comparing *their tool's bug rate* to *competitors' tools' bug rate*, whereas I understood them to be comparing *their tool's bug rates* to *commercial software bug rates*.
Here's my take on this. First, they are talking about their automated (?) tool modifying existing code. In a typical one million lines of COBOL code, most lines have nothing to do with date manipulation, and therefore do not need to be modified. Some lines (SWAG: 1%) are date-related, and of course would have to be modified. Taking my SWAG with the whole grain of salt it is worth would mean that in one million lines of customer code, there are 10,000 lines having to do with date manipulation, which have to be (automatically) found and fixed. In this context, to have error rates of 0,1 or 2 lines per 10,000 seems to me to be good, but not impossible, since the code and logic changes required for Y2K fixing are quite simple and mechanical. It also seems to be a bit of a meaningless statement, because if they could identify one or two bugs, wouldn't they fix them, therefore bringing their error rate down to zero?
Second, bug rates for useful commercial software packages in widespread use are surprisingly high. However, this is because applications are far more complex (resulting in many minor bugs) than simple date remediation tasks. So comparing error rates like they did does not seem to be a fair comparison.
- Daniel |
