Even better if something already on the books can be used. I agree that more laws is something to be avoided. In any case we need to make it known to people who can bring it into play. John T Apa [log in to unmask] L-3 CSW (801) 594-3382 640 North 2200 West PO Box 16850 Salt Lake City, UT. 84116-0850 >-----Original Message----- >From: Roepe, Marsha S. [SMTP:[log in to unmask]] >Sent: Wednesday, December 30, 1998 11:04 AM >To: [log in to unmask] >Subject: Re: Language Efficiency > >I don't really think we need another law. I think this can easily fit under >the existing Goverment Performance and Results Act. The issue might just be >finding which agency or group wants to collect it in a central location, and >letting the others know about it. I can think of several that might be >tempted by this like STSC at Hill AFB, or DCMC Software Center of >Excellence, or maybe SEI at CMU. > >Marsha > >Marsha S. Roepe >DCMC Lockheed Martin Marietta >770-494-9815 > > > >-----Original Message----- >From: John Apa [mailto:[log in to unmask]] >Sent: Wednesday, December 30, 1998 8:59 AM >To: [log in to unmask] >Subject: Re: Language Efficiency > > >You've made an excellent point. Congress should. The paperwork reduction >act requires the government to audit the amount of time spent filling >out peperwork, why not have similiar requirements for software >development? > >Does anyone have any contacts in Washington that we could use to >initiate such discussion/legislation? The big push to make government >efficient has not really happened as was promised, maybe this is a >suitable topic for our representatives to begin discussing. Maybe not as >entertaining as the current scandal but certainly of practical worth to >the country as a whole. > >It should be an achieveable task if we limit the discussion to just that >of improving the efficiency of software procurement and management. >There are many examples that draw attention to the problem. I think it'd >be a success if we were able to get a discussion started. > >I'd encourage everyone to contact their representatives if it hasn't >already been done. > >All great expeditions begin with a single step.... > >John T Apa [log in to unmask] >L-3 CSW (801) 594-3382 >640 North 2200 West PO Box 16850 Salt Lake City, UT. 84116-0850 > > > >>-----Original Message----- >>From: Robert C. Leif, Ph.D. [SMTP:[log in to unmask]] >>Sent: Wednesday, December 30, 1998 8:36 AM >>To: [log in to unmask] >>Subject: Re: Language Efficiency >> >>To: Robert Eachus et al. >>From: Bob Leif, Ph.D. >> >>I like your data. However, it is still anecdotal. It is possible to do a >>cross-over study. However, as we agree, it can not be blind. >> >>The bottom line is that the paucity of data clearly demonstrates that good >>manufacturing processes are NOT being followed in the software field. I >>suspect that by now must of us agree that the Ada mandate should have been >>replaced by the DoD being forced to keep decent data. If CMM can be applied >>to the contractors, why not force the Government agencies to employ ISO or >>some other reasonable standard for software acquisition. This standard >>should include obtaining and maintaining total cost and reliability data. >> >>Congress should require that DoD and other Government agencies analyze the >>results of their previous software practices and create a database for >>monitoring throughout their lifecycle all future software projects. >> >>> -----Original Message----- >>> From: Team Ada: Ada Advocacy Issues (83 & 95) >>> [mailto:[log in to unmask]]On Behalf Of Robert I. Eachus >>> Sent: Tuesday, December 29, 1998 11:11 AM >>> To: [log in to unmask] >>> Subject: Re: Language Efficiency >>> >>> >>> At 04:49 PM 12/26/98 -0800, Robert C. Leif, Ph.D. wrote: >>> >>> >Fortunately, our universe is restricted to software development. >>> >Unfortunately, I do NOT believe that a true double blind >>> crossover study is >>> >even conceivable. This would require the same project being developed in >>> >both Ada an another language. However, I believe that it is impossible >>> >because there is no straight-forward way to organize an experiment where >>> >neither the monitor (teacher) nor the student (user) know which >>> programming >>> >language they are using. >>> >>> Okay, I have to put in my own two cents as a statistician. ;-) >Neither >>> traditional single or double blind studies are possible because >>> in any case >>> the patient (programmer) knows what language he is writing in. But it is >>> fairly easy to do a study where neither placebo or Hawthorne >>> effects occur. >>> The important thing is not to have the same programmer, or programming >>> team writing the software in two languages--each sample has to >>> approach the >>> problem as new. Basically this has occured at several places, probably >the >>> most conclusive was at SUNY Albany. >>> >>> My "study of studies" synthesis of what I have seen is that Ada (83) >is >>> about five times more productive from design through integration and test >>> than C or Fortran. But putting on my Operations Research hat instead, the >>> interesting--and totally obvious in hindsight--conclusion is one that I >>> have stated here many times. The major difference is that in Ada, coding >>> is done means both that and that the software is very nearly complete. >>> (Testing remains, and usually some GUI tweaking.) In other languages, it >>> is not unusual for 90% or more of the source lines to be changed after >>> "coding is done." On one (Fortran 77) project I remember vividly because >>> we had the numbers, there were 560 KSLOC of changes to a (final) >>> 300+ KSLOC >>> project that was just over 200 KSLOC when "coding was done." On >>> the other >>> hand, I worked one Ada program where there were 17 lines changed between >>> handover to integration and test and six months after fielding. (And >over >>> half of those changes were clarification of error messages or correcting >>> typos in same.) >>> >>> I know I'm preaching to the choir, but it took a lot of getting used >to >>> fifteen years ago. We were converting some tools from Multics to >>> the DPS6, >>> and needed to translate them from PL/I to Ada. Even though we built >>> several translation tools to help in the process, most of the "hand work" >>> time was spent dealing with cases, error or otherwise, that the PL/I >>> programmer hadn't considered. Most of those changes were backfit into >the >>> PL/I, and they became "just as good" as the Ada versions. Our conclusion >>> was that, in other languages it can be up to ten times as >>> expensive to turn >>> out product quality code than a one-off kludge, but in Ada, the >difference >>> is under 50%. >>> >>> Robert I. Eachus >>> >>> with Standard_Disclaimer; >>> use Standard_Disclaimer; >>> function Message (Text: in Clever_Ideas) return Better_Ideas is... >>>