TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

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 11:59:47 -0400
Reply-To: Tom Rhoads <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
From: Tom Rhoads <[log in to unmask]>
Parts/Attachments: text/plain (38 lines)
Roger,

This is not an "anti-Ada" argument, but is really an anti-process argument. You said:

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).
[Tom Rhoads]  
You can change this to simply "project A uses a sound development
process and project C starts coding immediately". It doesn't change the rest of the argument, so for this case language choice is irrelevant.

[Tom Rhoads]  
The argument that the cost is in the design assumes that the design
and the documentation that goes with it is useless. You say:
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.
[Tom Rhoads] If it is true that all that design work was useless paperwork which delayed the identification of a flaw in the design, then coding (in any language) right away would be the right way to go.

My experience is that the sooner you start writing code, the longer it takes to identify problems and the longer it takes to complete the system. It is also less likely that the end product will meet the needs of the customer.

I believe the reason you are having trouble refuting the argument is that it is based on a false premise that following good software engineering process adds nothing to the development of software.

Tom
===================================================
Tom Rhoads                            [log in to unmask]  
Vergennes, VT 05491, USA 
 
"I have learnt silence from the talkative,  toleration from the intolerant, 
 and kindness from the unkind;  
 yet strange, I am ungrateful to these teachers.  - Kahlil Gibran
===================================================

ATOM RSS1 RSS2