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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.object:2768 comp.lang.ada:4997 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!bionet!agate!stanford.edu!msi.umn.edu!sctc.com!stachour From: stachour@sctc.com (Paul Stachour) Newsgroups: comp.object,comp.lang.ada Subject: Re: ada-c++ productivity Keywords: Looking for a few lazy men Message-ID: <1991Mar18.231721.2082@sctc.com> Date: 18 Mar 91 23:17:21 GMT References: <1991Mar15.224626.27077@aero.org> <1991Mar16.000624.2513@leland.Stanford.EDU> <1991Mar16.205228.4268@grebyn.com> <1991Mar17.142756.25676@ecst.csuchico.edu> Organization: SCTC List-Id: >>from the Feb. 11 issue of Federal Computer Week: >> >> "The board upheld a decision by the Air Force to award a contract to >> a high-priced bidder based on a measure of productivity that equals >> three lines of Ada code per programmer per day. ... > I would like to > know what in this world could reduce a serious programmer's > productivity to these levels. >email: rreid@cscihp.ecst.csuchico.edu ----- This question reminds me of the discussion in Gerald Weinburg's "The Psychology of Computer Programming". If I remember it right, it was a discussion between two programmers. Programmer B had just completed reprogramming a task originally given to programmer A. A was complaining about the speed of B's code, pointing out that A's original code was much faster. B replied with something to the effect that << But your code isn`t correct. Mine is. If mine doesn't ahve to be correct, I can made it as fast as you want.>> The point about productivity is that it can only be properly measured for "correct" code. And knowing what the characteristics of the code is makes is correct or not. For example, suppose I have a set of C-code. I compile it on 6 different C-compilers. It compiles without error, executes, and gives the same "right" answer on all. Now I give this code to 7 different programmers. They each compile, link, load, and execute it. For those 7 programmers, each of which used a different C-compiler, they all gave the wrong answers. Yes, I may have had great-prodcutivity in my original code. But if everyone else gets the wrong answers due to the fact that I don't know about a critical environmental component, or fail to document it, or fail to note that most C-compilers for physical-memory multi-tasking systems will not get the answer right, is my code correct? And given the time for all of them to discover it, how much prodcutivity was there really? I can give you a great lines-of-code productivity feature if: 1) I can presume all my inputs are correct. 2) I can presume all the subroutines I call are correct. 3) I can presume that the hardware never flips bits. Nor are there any other hardware errors. 4) I can presume that the compiler always generares correct code. 5) I can presume that I have enough memory and CPU cyles so that I can always think "clarity" instead of "make it fit" or "do swapping yourself". 6) All my users speak English so that I don't have to worry about how to handle multi-lingual error messages. 7) My cleanup routines will always get called on power-down or any other kill-condition so that my disk-data will always be consistant. 8) The client has a clear, simple, and unabigous specification so that I can spend all my time designing and implementing instead of trying to figure out what he really needs, instead of what he says he wants (which is full of contradictions). 9) I don't have to be compatible with existing applications that process the same data. 10) I have no numerical problems with overflow or zero-division. 11) I am working on a small enough project, in one single location, that I can get questions answered promptly. 12) I am allowed to work with hardware that is documented, instead of "new improved hardware" for which no documentation yet exists, and I have to play trial-and-error to see what it does now (which may be very different next week). 13) When I'm forced onto new hardware and software in the middle of a project, they are actually compatible with the old. All of these, and more, are assumtions that are often false. Sure, in the context of a simple, university-level, class assignment that got thrown away as soon as done, I have great productivity also. How many students at the university where you go/teach could write a resuable component for something as simple as a stack? I'd bet that 95% couldn't. I base that on me, my colleages, and those I teach. I base that on the fact that most hardware can't even do a shift properly (well, at least the way that the documentation says it does it). If one accepts the premise that 90% of good-code is for the conditions that happen less than 10% of the time (personally, I'll even say 1% of the time), then one can get a 10-fold increase in productivity by merely ignoring error-conditions. And if you buy component code from a commercial vendor, as we sometimes do, you can make some pretty big discoveries of bugs. We bought some code. We've used it for several years. In the first year, we found only a few bugs. In the second year, we really started to use to code, and found a few mode. In the third year, we discovered that there were enough seldom-happen items not covered by the code that it was not useful. And so we are re-writing it. And this time (I hope) we will test it. I could go on and on about the groups that I've seen and worked close-to that claimed to have "great productivity". A few did. But most merely turned out code fast. And that code was full of headaches for long-time to come. Enough for now. ...Paul -- Paul Stachour SCTC, 1210 W. County Rd E, Suite 100 stachour@sctc.com Arden Hills, MN 55112 [1]-(612) 482-7467