TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

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

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

Print Reply
Roger Racine <[log in to unmask]>
Wed, 9 Jun 1999 11:29:10 -0400
text/plain (46 lines)
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