Project C would eventually do the design documents? Are you sure? Will they
at all accurate? Will you have the design documents for Version 1 by the
time you are making changes in Version 2? This isn't about language, it's
about cutting corners and deferring costs. Just because you don't do the
design/architectural/documentation work before you code, doesn't mean you
aren't going to do it. You have no choice. I don't believe that anyone can
produce a complicated system without a design or an implied architecture.

Hopefully not to bad a rant......

How many of us have worked with these hackers who run out and do all the fun
coding only to leave the project when the boring paperwork has to be done?
This part of your case has nothing to do with language, but whether or not
you've hired software engineers or programmers. The longer I'm in this
industry the better I understand the difference between the two. It seems
that most companies have a very vocal group of hackers who follow their own
process (ad hoc, if anything) and will only do c++ for microsoft (the
license of which specifically states that it is not to be used for any
critical, safe, or high-reliable task), I won't say anything about their
compiled job security. I think most companies are more worried about these
undisciplined programmers quitting, rather than if a good quality job is
being done. I'm not impressed with the caliber of most of the students being
turned out from CS programs. Seems they don't actually write any real code
these days. I hope the trend of teaching Ada in schools continues, because
we need to teach these future programmers and SW engineers how to do more
than hack code. Who wants to travel to Mars on a craft that's powered by c++
and MFC? "It took use 5 years to make the 3 month trip, we had to reboot a
few times, and we lost our nav to the blue screen of death!" Sounds like a
modern Donner party waiting to happen.

I'm currently working on a system that is half Ada and half c. A prototype
that got fielded and was never formally developed, oh yeah, the
documentation will be done later (that was 5 years ago, the original people
have been gone for 3). The Ada and c code both do identical tasks but run in
different boxes. I'm just starting to collect metrics on what it takes to
make changes or add new features. I'll tell you one thing, the changes made
to the Ada code work and require much less integration time. Probably
because Ada doesn't let you put in all those cool side effects and coding
tricks. I'd much rather try to figure out poorly written Ada code than
average c code.

I have also prototyped in Ada, sometimes in races with c folk. My coding
wasn't done first, but my working prototypes were. Where I was at the time
we didn't release prototypes, we learned from them and the did the actual
development with a real understanding of what the customer wanted. If you're
blaming Ada because you can't meet a budget then I think you really need to
take a look at the people you've hired. Are they SW engineers or
programmers? You need a mix, and someone has to maintain the discipline to
do a good job. You can't test in quality, it has to be engineered in.

You can have any two: Good, Cheap, or Fast. But not all three!

A little raving.....

If Ada is going to fail because it is to 'process focused', then what does
that say about the state of the software profession at large? The hardware
and firmware guys are using reusable components, visual modeling, and
upfront design. All these things have been proposed for software, yet to
many people refuse to adopt them. ACM is always trying to promote the "SW
Professional", are we really living up to this? I certainly try. The people
that work for me do their design and documentation up front, they have no
choice. I will not going to give them a budget and wait until they get half
way through to find out that they don't understand the problem. It
interesting to see how smooth thing go when the design is done up front and
it's documented.

Well, that's about a $0.02 reply & $0.98 or ranting and raving.

John T Apa                              [log in to unmask]
L-3 CSW                                 (801) 594-3382
PO Box 16850                            Fax: (801) 594-2195
640 North 2200 West                     Salt Lake City, UT. 84116-0850



> -----Original Message-----
> From: Roger Racine [SMTP:[log in to unmask]]
> Sent: Wednesday, June 09, 1999 1:31 PM
> To:   [log in to unmask]
> Subject:      Re: Anti-Ada Arguments
>
> I obviously did not word the argument well.  I will try again.  By the
> way,
> these are close approximations to two real projects of the same type
> (guidance, navigation and control).
>
> I used too much documentation in the statement of the original argument,
> but that was (part of) the reality of the project.  By the way, Project C
> would eventually create design documentation later in the effort.  The
> design review was done using viewgraphs (not under version control; much
> cheaper than a design document).  But everyone is right that this is not
> pertinent.
>
> Pretty much all the arguments in favor of Ada assume a fairly expensive
> front-end load to development costs, no matter what process is used.  The
> arguments I have used and heard for Ada are all about integration and
> maintenance.  It is always conceded (please give me experience otherwise)
> that Ada costs more to design and code than C (and, by extension C++ and
> Java.  Not that these last 2 are known to be true, but people do make that
> extension).  These are similar arguments to those used for documentation
> and reviews, so they somewhat go hand in hand.
>
> In my opinion and experience, Ada does not lend itself well to rapid
> development.  Defining the types, laying out the packages, etc., take time
> up front.  Yes, one can use the predefined types for all data, but then
> Ada's strong typing will not help in integration and maintenance.  And
> packages can be created that just hold a bunch of procedures and
> functions,
> as in C files, but then Ada's modularity features will not help in later
> phases.  So while I agree that it is somewhat an apples and oranges
> comparison, I will also mention that Project C came after Project A, and
> was something of a pendulum swing due to the problems encountered in
> projects like Project A.  So, while the whole $10M cost (not the real
> number) would not have occurred in Project A if it had put off the
> documentation and done iterative development, the cost still would have
> been significantly greater than in Project C.  PLEASE PROVE ME WRONG.
>
> I have used incremental development in all the projects I have worked on
> for the last 23 years, and am a great advocate of that method.  I am also
> a
> firm advocate of keeping the customer in the loop.  But it is not always
> possible.  One project I worked on, everyone was so intent on meeting an
> impossible schedule that the customer would not allow requirements to be
> reviewed, even though they insisted that the development team be
> co-located
> with the customer.  That caused some problems at the design review.  But
> that is also off the subject.
>
> So I think the argument comes down to this:
>
> There is a higher cost-overrun risk using Ada than using C, C++ or Java,
> due to the extra work done to generate the Ada code.  A good development
> process will help lower the risk, but not get rid of it.
>
> > I have an interesting anti-Ada argument that I am having difficulty
> > refuting.  Any help?
> >
> > The argument goes like this:
> >
> > -----------------------
> > Project A uses Ada.  Project C uses C (use C++ or Java if you like).
> >
> > 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).
> >
> > By the time Project A is ready for a detailed design review, they have
> > thousands of pages of design documentation, they have done walkthroughs
> on
> > everything, and they have spent a good deal of money.  By this time,
> > 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 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."
> >
> > 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.
> > -----------------------
> >
> > I don't think it is sufficient to simply say "The money will be made up
> > during maintenance."  While probably true, the initial cost overrun
> might
> > cause the program to be canceled.  And the total cost, while possibly
> > higher for the C case, is likely to be more deterministic (you know how
> > many bugs are likely, but it is much more difficult to tell how many
> major
> > design problems will occur).
>
> Roger Racine
> Draper Laboratory, MS 31
> 555 Technology Sq.
> Cambridge, MA 02139
> 617-258-2489