OK, I think we've got enough data to not be confused about your
examples.  I'm not totally sure.  Here's how I understand it:

1. Both Project A and Project B did incremental development.

2. Both hit a snag at detailed design review for increment 1 that
   required starting over.

3. To get to detailed design, Project A took about 65% of the
   increment 1 budget.

4. To get to detailed design, Project C took about 20% of the
   increment 1 budget.

OK, we don't fire everybody on Project A.  That comment came from the
(mis)understanding that they burned 65% of the PROJECT budget to get
to detailed design, and still hadn't communicated with the customer
well enough to find the time bomb.

I'm still not sure I totally understand.  You said that, at nominal
detailed design for the first increment, Project C had "a first
iteration of the finished product."  That is, they developed the
first iteration of their system before they developed the first
increment of their system.  But that wasn't prototyping. I hope
you can see why I find that confusing.

Here's how I understand it.

Project A did a formal waterfall within the increment.  This makes it
credible to spend around 65% of the increment's budget to get to
detailed design review.

Project C developed one or more versions of their system, or of some
critical components, rapidly and without a formal design phase, before
their nominal detailed design review.  They showed these to the user,
intending to throw part or all of them out if the user response
indicated that radical rework was needed.  They used these prototypes
as their design documentation.

Overall, I would say that your company should learn a couple of
important lesson from Projects A and C:

- Develop key elements of the design early and verify them
  with the user.

- Simplify your design approach for early increments.  This
  doesn't require you to do sloppy work, just do less work;
  be aware that your early analysis and design are tentative
  and likely to change.

Both of these can be done with Ada.

It's commonplace for key elements to be prototyped (or pre-developed,
or fast-tracked, or done in research implementations, or -- pick your
own word).  This is done during design or even requirements analysis,
using Ada or any other language.  We did this for the Space Station
Training Facility.  It's something that people have been doing since
before computers existed (although not for software, of course).

And Ada's constructs for modular design (packaging and child packages)
make it simple to carve out pieces for pre-implementation, even before
you know the overall design.

Hurry-up development is an engineering decision.

I'll grant that less-formal development is not "textbook method."
Textbooks exist to explain formal methods, and the language features
that support them.

But it's certainly possible to work less formally in Ada.  And, it is
NOT bad engineering.  Bad engineering is using the WRONG level of
formality, too low or too high, for the job at hand.  It does take
experience to know when to apply the methods and use the features.

Here are a few pointers:

- If your system is simple enough, you can skip formal pre-coding
  design.  You represent your design decisions in code, building up
  your understanding of the system as you code.

  Ada gives you some good facilities for breaking out work into units
  (packages) that reflect your current idea of how the system will
  work, and that are easy to reorganize when that idea changes.

- Ada lets you document your design ideas in code in ways that let the
  compiler help you keep your thoughts straight, which usually gets
  you to a WORKING version faster.

- There are shortcuts, like documenting design intent with subtypes of
  standard types, instead of creating new types.  This will still
  locate errors for you when data goes out of range, but it lets you
  mix different kinds of data freely.  If you're having problems, you
  can turn a limited subset of your subtypes into full types -- the
  compiler will then force you to document all your type mixing, and
  you may well debug your problem before you run another test.

  Actually, this isn't so much a trick as a matter of learning when
  to create new types.  Most new Ada coders -- perhaps most Ada
  coders -- create way too many new types.

Approaches to incremental development have been in the Ada literature
for years.  I believe there have been articles through the years in
ACM SigAda's Ada Letters.  I know I have seen others, at conferences
and what-not.

Perhaps the Ada-oriented folks there have been tending their own
rosebushes and not working to stay current.  (I've had that problem
myself.)  Or perhaps they'd jump at the chance to show how flexible
they are, but nobody has tried it with an Ada project.

But, if I understand your example projects correctly, you have a
people issue or a management issue, not a language issue.  If all the
Ada users in your company are dedicated formalists, and all the C
users are dedicated informalists, then you'll get the dichotomy you
described -- but it's due to the people, not the language.

Best,
Sam Mize

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