TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Content-Type:
text/plain
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
"Brashear, Phil" <[log in to unmask]>
Date:
Wed, 9 Jun 1999 11:58:01 -0400
MIME-Version:
1.0
X-To:
Roger Racine <[log in to unmask]>
Reply-To:
"Brashear, Phil" <[log in to unmask]>
Parts/Attachments:
text/plain (66 lines)
Prevention:
Good Ada development process should include careful requirements
development, including prototyping.  The customer should be heavily involved
at these stages, or s/he is not likely to accept the developer's
interpretation!

You can't blame this on Ada -- not even on sound engineering practice --
just on a failure to implement sound engineering practice.
Of course, since it was an Ada project, then Ada gets the blame.

Phil


> -----Original Message-----
> From: Roger Racine [SMTP:[log in to unmask]]
> Sent: Wednesday, June 09, 1999 11: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
> 617-258-2489

ATOM RSS1 RSS2