LISTSERV mailing list manager LISTSERV 16.0

Help for TEAM-ADA Archives


TEAM-ADA Archives

TEAM-ADA Archives


TEAM-ADA@LISTSERV.ACM.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEAM-ADA Home

TEAM-ADA Home

TEAM-ADA  June 1999

TEAM-ADA June 1999

Subject:

Re: Anti-Ada Arguments

From:

Samuel Mize <[log in to unmask]>

Reply-To:

Samuel Mize <[log in to unmask]>

Date:

Thu, 10 Jun 1999 18:22:44 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (183 lines)

Greetings,

I wish I had a good set of papers and published case histories to
refer you to -- perhaps some of the consultants and authors on the
list can provide some.  All I can do is tell you my own experience
and observations.

> I have compressed this a bit to make it less long.

Good plan.  Blaise Pascal (I think) once wrote "sorry this letter
is so long, I didn't have time to make it shorter" (paraphrase).

I'm not going to respond to everything quote-by-quote, but I will
use quotes to introduce my points.

- - - - -

First, to answer a specific question:

> >So the real numbers for your worst case might be that the Ada program
> >spent 25% instead of 20% of its budget, and will spend 80-90% of the
> >original budget instead of 90-100% to start over.
>
> My number was 65%.  Where did you get 20%?

Project C took 20% of its budget to get to rework city.  Project A
will take 25% instead of 20%.

- - - - -

> >> In the simplest
> >> case, where a design flaw is found requiring starting completely over,
> >In this case, the management team and top-level technical staff
> >should be summarily fired.
>
> I can think of 2 major Ada projects where something like this happened (not
> firing the management and top-level technical staff).  I imagine others
> can, also.

Really -- where the entire requirements analysis, preliminary design,
first-increment detailed design and code had to be scrapped entirely?
Nothing was saved, nothing reused?  My, my.  I've seen things that
required significant replanning and rework, but nothing that flushed
the entire work product to date.

- - - - -

> This is simply assuming -standard practice- ... in both cases

If you consider large, requirements-driven, front-loaded, traditional
projects as the baseline for Ada, I get to pick Microsoft as the
baseline for C.  Now let's talk about risk, schedule slips, late
deliveries, crashing software and products that the users hate.  :-)

- - - - -

> -standard practice- ... in both cases (no prototyping).

You specifically said that Project C used prototypes to elicit
customer response and reduce requirements risk, and Project A did
not.  My argument is that you can do so with Ada too, and that this
is the key difference between Projects A and C.

Ada's facilities support a continuum of methods.  For highly
reliable, long-lived system, like missile avionics, it supports a
front-loaded life cycle.  But it can also be used fast and loose.
For an incremental development where user feedback will influence
design, you'd pick a middle road.

- - - - -

> to simply get a well-designed first iteration of a given
> set of functionality, it takes longer with Ada than with other languages.

You must compare well-designed first iterations, or not-designed
first iterations.  If you compare the well-designed to the
not-designed, the well-designed one will always take longer.

But really, nobody can make something work without design.  They
simply design as they code, and record their design decisions in the
code (or remember them).  This is both possible and easier in Ada.
You can use subtypes to indicate design intent, for instance, without
bringing in the overhead of strong typing.

At equivalent levels of design before coding, the Ada project will
probably use 10%-30% more time -- that is, if the C project took 10%
of schedule, the Ada one will take perhaps 11%-13% of schedule.

And the modularity and clarity that cost you that 10%-30% will speed
up development of later increments, unless every increment is totally
unrelated to the previous one.

- - - - -

> The 65% and 20% were made up to make the end costs end up very close, but
> they are not way off from what I heard back in the early 80s when I started
> learning the language.  And I have never seen any data stating the opposite.

Anybody got references or case studies handy?  I should HOPE we've
learned something in the last 15 years!

Incremental development became popular in and after the late 80s[1].
Any numbers from the early 1980s compared waterfall-model projects to
undesigned, un-incremental, chaotic projects.

There have been papers in ACM's Ada Letters and elsewhere about
incremental development in Ada, but I don't have a library handy.

I can't see how Project A spent 65% of the schedule before they
showed the customer a first increment, unless they did a formal
requirements analysis, a formal preliminary design, and a formal
detailed design prior to coding their first prototype.  That isn't a
language issue.

It may be a cultural issue.  I've done iterative development in Ada,
and it works great.

Ada's packages and modular constructs let you define what small part
of the system you are doing "today," and chop out, in an orderly
fashion, what you will do "tomorrow."  You can reflect upcoming
design issues, for instance with stub packages and procedures, and by
using Ada as a PDL (there's an IEEE standard for that).  Or, you can
just leave out whatever you don't want to code today.  Tomorrow the
compiler will help you find every place you need to integrate it.

Would that approach shock Ada developers in 1985?  Perhaps.  It's
commonplace today.

For example, NASA's Space Station Training Facility was built with an
incremental approach.  In fact, it's STILL being built that way, as
it must change when the Station does.  No other approach is possible.
It uses a more front-loaded approach than the language requires --
for example, there was a full requirements analysis phase before
anybody did any design or coding in any language -- but I'm sure it
didn't cost 65% to get to detailed design for the first increment.

I've also coded Ada rapidly, without using its high-level design
features.  It comes close to the speed of hacking in C, yet you get a
lot of help in catching errors in your rapidly-written code.  Plus,
you get higher-level constructs like

  for I in Inputs'Range

which obviates declaring I, keeping the max value of Inputs around,
and remembering to increment the counter.

(OK, if you just want to look at time to finish writing code, this
doesn't help.  If you are looking at time to finish making the code
WORK, Ada comes out a lot more even.)

> Compare Ada text books with C books.
> ...
> Don't say "The Ada people could have done it the same way as the C people."
> That is not the way anyone is teaching them to do it.

The Ada people could have done it the same way as the C people.

Sorry, couldn't resist.

And no, I wouldn't want them to.  But I would expect a disciplined,
decently-coded first increment in Ada to take 10%-30% more time, not
325% more time.  It wouldn't be done to the same coding standards as
used for a high-reliability, long-lived product like avionics, and it
shouldn't, if that isn't needed.

I will grant that one weakness in current education is teaching
people when to NOT use some methods.  It's only "engineering" if we
select the APPROPRIATE methods for the job, not if we over-engineer
the simple things (the full architectural drawings for the outhouse).

Best,
Sam Mize

[1] Barry Boehm introduced the Spiral model in ACM SIGSOFT Software
Engineering Notes in August 1986, and to a larger audience in IEEE
Computer in May 1988.  Frederick Brooks wrote that incremental
development was a promising approach for future work in "No Silver
Bullet," IEEE Computer, April 1987.

--
Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2017
November 2017
October 2017
September 2017
June 2017
May 2017
April 2017
January 2017
December 2016
November 2016
October 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
December 2010
November 2010
October 2010
September 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
June 2007
May 2007
March 2007
February 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996

ATOM RSS1 RSS2



LISTSERV.ACM.ORG

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager