From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 21 Jun 93 15:18:08 GMT
From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.
reston.ans.net!europa.eng.gtefsd.com!capella.tsc.gtefsd.com!eric@ucbvax.Berkele
y.EDU  (Eric Peterson)
Subject: Re: Defending Greg
Message-ID: <204jfg$lar@europa.eng.gtefsd.com>
List-Id: <comp.lang.ada>

wellerd@ajpo.sei.cmu.edu (David Weller) writes:
|> [...]  Ada in no way mandates top-down design.  To the contrary, I've
|> found that it is MUCH easier to do built-a-little, test-a-little in
|> Ada than it is in C (and a little easier than C++).  Your mileage
|> may vary -- apparently it has :-)
And which features of Ada make it easier to build-a-little, test-a-little?
(as described in this sample):
A certain application requires some data among many other requirements.  The
developer writes some code to obtain data the simplest way and print it out. 
The developer then spruces up the design by generalizing the SW architecture,
improving fault tolerance, the variety of data handled, adding data analysis,
adding better displays, etc.  At each point the developer makes some changes
and tests them.  The developer gets SW in the customers' hands within days and
allows them to refine their requirements.
|> 
|> >As program requirements change, designs have to change and program
|> >requirements change when you get the product out in the field.  Ada
|> >supporters (especially those who have exaggerated its benefits) maintain
|> >that development costs increase the further you get into the
|> >implementation.  Believing this fallacy, they design and design while
|> >the real world waits and waits for the results so they can tell them
|> >it's all wrong and they should start over.
|> 
|> Yup.  Sounds like you've got some sour grapes from a project that followed
|> a rigid waterfall process.  I could go into a discussion about controlling
|> requirements, prototyping design, formalizing processes, but such concepts
|> usually go over the heads of many C programmers, so I'll not bother. :-)
Yes, unfortunately all I seem to know is how to produce as good a product as
possible as quickly as possible :)  But seriously, please direct me to some
resources so perhaps I can formalize what I infer from my experience.
|> >
|> >The waste I see every day is top-down designers in long meetings
|> >producing designs which are worthless in the long run due to
|> >inadequate, incomplete, and impossible requirements.
|> >
|> 
|> Well, don't just sit there!  Roll up your sleeves and do something about
|> it!  You have two choices otherwise: Leave your job or shut up.
Good advice, my sleeves are rolled up!
|> 
|> I just hate it when people confuse bad project management for a language's
|> shortcomings.  Ada sure has been the scapegoat of the 80's & 90's.  I
|> agree with Greg about some of the outlandish mismanagement of people who
|> are supposed to be promoting things associated with Ada, but Ada itself
|> is a very usable, well-designed language (even WITHOUT Ada 9X!).
|>
I think Ada deserves what it got, because in many cases the same people who
promoted top-down design also promoted Ada as a vehicle for it, i.e., Ada was a
language in which system designers could write pseudocode which was exactly the
same as deployed code.  This feature is, at best, irrelevant in the bottom-up
approach I described above.  Additionally, Ada proponents still promote some
top-down concepts as requirements-based reuse, formal specification, etc.  Why
do these people still exist?

Eric.  (still my views, but edging a little towards the establishment).