TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To: Roger Racine <[log in to unmask]>
Date: Wed, 9 Jun 1999 08:49:34 -0700
Reply-To: Gene Ouye <[log in to unmask]>
From: Gene Ouye <[log in to unmask]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Parts/Attachments: text/plain (63 lines)
You really aren't talking about language issues here, you're talking about
two different development lifecycles.  On project A you're talking about a
waterfall lifecycle, on project C it sounds like something more iterative
and/or incremental.  Use of Ada does not preclude use of an iterative,
incremental lifecycle.  On the contrary, I'd claim that it would be easier
to use Ada in that kind of lifecycle than C...

Gene Ouye <[log in to unmask]>

-----Original Message-----
From: Team Ada: Ada Advocacy Issues (83 & 95)
[mailto:[log in to unmask]]On Behalf Of Roger Racine
Sent: Wednesday, June 09, 1999 8:29 AM
To: [log in to unmask]
Subject: Anti-Ada Arguments

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