TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Samuel Mize <[log in to unmask]>
Wed, 9 Jun 1999 12:01:26 -0500
text/plain (116 lines)
Tom Rhoads wrote:
>
> Roger,
>
> This is not an "anti-Ada" argument, but is really an anti-process
>argument.

I agree that it is a process argument and an anti-waterfall argument.

Tom quoted Roger:
> 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).

Roger also wrote:
> By this time [equivalent to design review for the waterfall project],
> 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 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.

So project C is using an iterative or "spiral model" method, and
considering their main design documentation to be their successive
prototypes.  For a UI-intensive system, this can be a fine approach.

I don't know that I would consider it to be all that slick an approach
for, say, a missile guidance package.  ("Here's our current prototype,
let's load it into a few Tomahawks and see how it does.  Oh -- they
cost how much?  You mean, each?")

And I would note that they are documenting their design somehow, if
only in code structure and identifier names.  Depending on the size
and complexity of the system, this may be a good approach.  If someone
wants to do that, I have a suggestion: use Ada.  Packages and types
make this MUCH easier.

As for a prototyping development cycle, there is absolutely no reason
to not do this with Ada.  In fact, Ada provides significant benefits
to a code-early approach.

- You can use package specs to control your interfaces, getting
  compiler-checked interfaces and fixing confusion between teams,
  early and at a low cost.

- You can build a lot of utility packages early, or more likely select
  the ones you want to re-use from previous projects.

- You can do UI prototypes, if you're building something with
  a UI, and integerate them with the real specs, getting assurance
  that the real system will come together properly.

- If you find that you've made a basic design error, the modularity of
  Ada packages generally limits the amount of code that will have to
  change.  Many times changes at the declarative level will "ripple"
  through the system and fix everything automatically, if you've coded
  carefully (e.g., using attributes and named constants instead of
  typing "magic numbers" directly into the lines of code).

- If you have to totally restructure, your old package structure will
  document what you were doing, and make it easier to move things around
  and ensure you haven't left anything out.

I'm not sure if there is much published on the prototyping benefits of
Ada, but there should be.  You might check at http://www.adahome.com and
the ACM SigAda web site.

Some people think that Ada is worse for rapid prototyping than C, but
that's because you can't slap together some bad code and get it to
kind-of run.  If you intend to upgrade and deliver the prototype (that
is, if it's an early version and not a complete throwaway), Ada beats
C for prototyping.  You can rapidly throw up a design structure, lay
in preliminary or TBD versions of code and have the compiler help you
find them later for upgrade, and just generally keep better track of a
series of exploratory versions.

Anyway, my experience with this kind of prototyping in C and Ada
suggests that Ada does NOT impede you, and it provides some advantages.

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

Project A is badly run.  Some projects have been run this way,
unfortunately.  Worse, some customers have forced their contractors to
work this way, either by refusing to stay involved or by being such a
royal pain to work with that the contractor firewalled them out of the
development loop in self-defense.  I'll agree that this is the
downside of the waterfall model: nothing in the model keeps this from
happening.  It requires a customer who will stay involved, and a
contractor with the skill to present ideas clearly.


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

Oh, Project C has a design review?  What are they reviewing if there
is no design?  You've got to make this fellow play fair.

What exactly is Project C doing, and how exactly does C support it
better than Ada?

Best,
Sam Mize

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

ATOM RSS1 RSS2