This question confuses design documentation and review with requirements
analysis and review.
Project A (at least in the summary provided) concentrates on design
documentation, but no mention is made of requirements analysis and review.
At the design review, a requirements interpretation issue comes up which
invalidates much of the design.
Project C concentrates on the interpretation of customer requirements by
providing multiple prototypes, and is less likely to discover a problem in
this area later.
When prototypes are appropriate in a system, they are much more likely to
reveal requirements interpretation problems than a paper statement of
requirements. A paper statement of requirements is important if there is a
need to validate that the implementation meets the requirements. If there is
no need to validate requirements on all or part of a project, a prototype
may be just as valid a way of stating requirements as a paper statement of
Perhaps the program managers for Project C felt that requirements were a
risk item, and the most important activity early in the program is to
validate the requirements.
Then there is a question of design documentation. Often, much of the
voluminous design documentation is unnecessary and is produced simply to
meet program requirements. The complete documentation must be produced well
in advance of design reviews, and the scheduling of these review usually
doesn't allow time for other activities such as prototyping.
A large program cannot be managed without lots of documentation, but it is
important to distinguish between the documentation that really contributes
to generating a good end-product and that which is superfluous. Every
documentation item that will not be kept up to date as the implementation
changes is a good candidate to be deleted.
It appear from the description that Project A is of a much larger scale than
Project C. Perhaps Project C was small enough to not need much design
Did Project C have maintainability requirements? If not, minimal design
documentation may be a good strategy to getting to the desired end product.
As others have said, all the above is regardless of which language Projects
A and C are implemented in.
> From: Roger Racine[SMTP:[log in to unmask]]
> Sent: Wednesday, 09 June, 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