TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Apa <[log in to unmask]>
Reply To:
Date:
Wed, 30 Dec 1998 11:50:33 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (167 lines)
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...
>>>

ATOM RSS1 RSS2