Re: ada-c++ productivity

[mfeldman@seas.gwu.edu (Michael Feldman)]

In article <1991Mar17.142756.25676@ecst.csuchico.edu> rreid@ecst.csuchico.edu (Ralph Reid III) writes:
>>    a high-priced bidder based on a measure of productivity that equals
>>    three lines of Ada code per programmer per day.
>>
>>    "A lower priced bidder, and others in the Ada community, said this
>>    standard is much too low.  The protester in the case, DynaLantic
>>    Corp, offered an average of ten lines of code per day per
>>    programmer.
>>
>>    "Three lines of code per day is absurd [as if ten wasn't], said
>>    Ralph Crafts, editor of a newsletter on Ada, and an expert
>>    witness for the protester.....
>> . . .
Hmmmm. Interesting to see this pop up on the net. It happens I was also
involved in this case (somehow they got the idea I was an expert in
something) and so have read the decision. You may recall that I posted
a question about productivity measures a while back; now you know why.

The answers I got were varied and interesting; the only generalization
in them was that nothing can be generalized. Going back to the Ed Yourdon et al
books of 15 years ago, one finds that in those days end-to-end software
productivity was cited in the neighborhood of 5-10 LOC per day, independent
of language. Yourdon et al were making those numbers an argument for 
high-level languages, because 5-10 assembler instructions and 5-10 lines
of HLL code clearly have different functionality, yet the studies showed
that the 5-10 was "language-independent." The purpose of "structured
programming" and all that was to raise the productivity. More recent
reports showed that indeed the range from doubled to 10-20 after using
these "new programming technologies" as they were called then.

In preparing for the case I dug into the literature, good professor that
I am. Everything I could find in the literature on Ada productivity on real
projects pointed somewhere in the neighborhood of 30-40 LOC/day. Remember
that these are _average_ numbers, end-to-end, including documentation and
all that. (sources: Reifer's productivity studies, WAdaS and TRi-Ada papers,
and the like). The 10 LOC/day offered by the company in question for a
relatively small project (~15k LOC) was, in my opinion, _quite conservative_
given the numbers I just cited. The company knew the application area.

That the USAF people should have derided the 10 LOC estimate as _overly 
optimistic_, preferring an absurdly low number of 3 LOC, sends me a
message that the government (or at least some people in it) are afraid
of Ada and/or not really interested in productivity. I'm under nondisclosure
or I'd post some details that are so sad they're funny. The administrative
law judge's decision is public record, so it's sage to comment. This guy
not only upheld the award (I figured he would because this was a contract 
where USAF had a lot of discretion) but gratuitously accused the company
of "low-balling," that is, bidding TOO-HIGH productivity in order to get the
contract.

Given the "where cost-effective" clause in the legislative mandate for
Ada, this case could be an awful precedent, because the government can
accuse anyone bidding high productivity (arguing Ada's cost-effectiveness)
of low-balling. Those in the government determined to resist any kind
of progress (it doesn't even have to be _Ada_ progress) can have a field
day shooting down high(er) productivity estimates. Let's hope most of the
government is too smart or has too high a sense of integrity to pull
tricks like this. Stay tuned: there may be appeals in the case.

My work in this weird case convinced me even more that this whole crazy
industry still doesn't really know how to estimate things. LOC/day is
not a terrific measure of anything. It's all we seem to have, though.
And people use it as though it were gospel.

Mike Feldman