TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show Text 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:
Roger Racine <[log in to unmask]>
Reply To:
Roger Racine <[log in to unmask]>
Date:
Wed, 9 Jun 1999 15:31:09 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (94 lines)
I obviously did not word the argument well.  I will try again.  By the way,
these are close approximations to two real projects of the same type
(guidance, navigation and control).

I used too much documentation in the statement of the original argument,
but that was (part of) the reality of the project.  By the way, Project C
would eventually create design documentation later in the effort.  The
design review was done using viewgraphs (not under version control; much
cheaper than a design document).  But everyone is right that this is not
pertinent.

Pretty much all the arguments in favor of Ada assume a fairly expensive
front-end load to development costs, no matter what process is used.  The
arguments I have used and heard for Ada are all about integration and
maintenance.  It is always conceded (please give me experience otherwise)
that Ada costs more to design and code than C (and, by extension C++ and
Java.  Not that these last 2 are known to be true, but people do make that
extension).  These are similar arguments to those used for documentation
and reviews, so they somewhat go hand in hand.

In my opinion and experience, Ada does not lend itself well to rapid
development.  Defining the types, laying out the packages, etc., take time
up front.  Yes, one can use the predefined types for all data, but then
Ada's strong typing will not help in integration and maintenance.  And
packages can be created that just hold a bunch of procedures and functions,
as in C files, but then Ada's modularity features will not help in later
phases.  So while I agree that it is somewhat an apples and oranges
comparison, I will also mention that Project C came after Project A, and
was something of a pendulum swing due to the problems encountered in
projects like Project A.  So, while the whole $10M cost (not the real
number) would not have occurred in Project A if it had put off the
documentation and done iterative development, the cost still would have
been significantly greater than in Project C.  PLEASE PROVE ME WRONG.

I have used incremental development in all the projects I have worked on
for the last 23 years, and am a great advocate of that method.  I am also a
firm advocate of keeping the customer in the loop.  But it is not always
possible.  One project I worked on, everyone was so intent on meeting an
impossible schedule that the customer would not allow requirements to be
reviewed, even though they insisted that the development team be co-located
with the customer.  That caused some problems at the design review.  But
that is also off the subject.

So I think the argument comes down to this:

There is a higher cost-overrun risk using Ada than using C, C++ or Java,
due to the extra work done to generate the Ada code.  A good development
process will help lower the risk, but not get rid of it.

> I have an interesting anti-Ada argument that I am having difficulty
> refuting.  Any help?
>
> The argument goes like this:
>
> -----------------------
> Project A uses Ada.  Project C uses C (use C++ or Java if you like).
>
> Project A uses good Ada development process and spends a lot of effort up
> front to make sure maintenance will be easy.  Project C starts coding
> immediately, and documents the design "later" (i.e. not at all).
>
> By the time Project A is ready for a detailed design review, they have
> thousands of pages of design documentation, they have done walkthroughs on
> everything, and they have spent a good deal of money.  By this time,
> Project C has had a number of demonstrations, has a good deal of problem
> reports (due to the usual C pitfalls), and has made a few major design
> changes based on the early demonstrations to the customer.
>
> At Project A's design review, the customer sees a major problem in the
> basic design.  There were interpretation problems with the requirements.
> The customer says they need the problem fixed.  The developer says: "That
> will cost $10M.  We have to update thousands of pages of documentation, go
> through all those walkthroughs again, etc."
>
> At Project C's design review, it is less likely that this will happen
> because the customer has been seeing the system being built.  But even if
a
> major design change is needed, Project C's cost will be much lower to make
> the change.
> -----------------------
>
> I don't think it is sufficient to simply say "The money will be made up
> during maintenance."  While probably true, the initial cost overrun might
> cause the program to be canceled.  And the total cost, while possibly
> higher for the C case, is likely to be more deterministic (you know how
> many bugs are likely, but it is much more difficult to tell how many major
> design problems will occur).

Roger Racine
Draper Laboratory, MS 31
555 Technology Sq.
Cambridge, MA 02139
617-258-2489

ATOM RSS1 RSS2