At 09:17 AM 12/18/98 -0000, Bill Taylor wrote:
>>    When you need software On Time and Under Budget
>>                      Choose Ada
>>
>>
>
>There is a danger that such a claim will undermine the credibility of the
>other (stronger) claims for Ada.
>It appears far too naive.
>
>Using Ada is no guarantee of delivering on time and under budget, just as
>using another language is no guarantee of failure to deliver on time and
>within budget (but it certainly helps!).
>
>Choosing an appropriate process is far more significant in this respect than
>choice of language.
>Poor management, poor process, poor design will never bring a project in on
>time and under budget, whatever language is chosen.
>
>Ada should be part of an overall strategy to develop reliable, predictable,
>safe software.

    This almost falls in the true but irrelevant category.  Process is
important to delivering software on time and within budget, but it is not
the whole story.  Use of Ada can sometimes fix otherwise impossible
schedules and budgets but not always.

    However, there are at least three occasions I am aware of where a
desision was made to switch from another language to Ada in the middle of a
project because the alternative was to declare the project to have failed.
In two of those cases, the final delivery was made in Ada within the
original schedule and budget.  In the third case, the budget had already
been exceeded and the schedule slipped when the switch was made.

    Now true, the switch would not have been successful if they hadn't also
switched to better software engineers and better engineering practice.  But
good software engineers, I hope, would never have gotten so deep in the
hole in the first place.

    One of those cases was even more interesting due to a different
discovery.  The intent was to rewrite the interfaces in Ada, and reuse
existing "working" C code where possible via pragma Interface.  It pretty
quickly became obvious that it was easier to redo the bodies of the
packages in Ada as well.  One estimate was that writing the bodies of the
packages was less than 5% of the entire effort.  (Writing packages specs
was over 30%, but that includes a lot of what should be called detail
design.  The rest was mostly design and (unit and system) test, with
integration and debugging effort less than 5%.)

    Another data point here.  Years ago, I wrote a package for generating
and printing bridge hands in Fortran.  (It had features that allowed you to
"bias" the output for bidding practice, such as North has at least five
spades.) Overall total effort was about a month.  To test out the random
number capability in Ada 9X, I redid the project in Ada.  (Ada 83 plus the
Ada 9X RNG packages.)  I wrote the requirements, did the detailed design,
wrote the code, fixed up a few formatting problems--and went to lunch.  The
whole process took under three hours.  (The version of this program
distributed as part of ADAR has the code for biasing the deals taken out,
but it amounts to a couple dozen  lines of code--and calls to
Ada.Command_Line.)

    The Ada was about 200 SLOC where the Fortran was closer to 2000, and
the Ada version had a much better random number generator. ;-)   However, I
have had several other similar experiences, and there have been several
cases where the productivity on an Ada project has been in the hundreds of
SLOC per DAY per staff member in some cases over multiyear projects with
more than a dozen members of the team. Yes this takes good people, but huge
performance benefits are possible.



                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...