From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.object:2752 comp.lang.ada:4983 Path: utzoo!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!seas.gwu.edu!mfeldman From: mfeldman@seas.gwu.edu (Michael Feldman) Newsgroups: comp.object,comp.lang.ada Subject: Re: ada-c++ productivity Keywords: Looking for a few lazy men Message-ID: <2881@sparko.gwu.edu> Date: 18 Mar 91 04:57:27 GMT References: <1991Mar15.224626.27077@aero.org> <1991Mar16.000624.2513@leland.Stanford.EDU> <1991Mar16.205228.4268@grebyn.com> <1991Mar17.142756.25676@ecst.csuchico.edu> Reply-To: mfeldman@seas.gwu.edu () Followup-To: comp.object Organization: The George Washington University, Washington D.C. List-Id: 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