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
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.
> -----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
> 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