Re: Ada Professional Questions

[emiya@AMES-VMSB.ARPA]

I've just read these two letters again, I think they best belong in
soft-eng.  They are broader scope than Ada alone.  How does any contracting
body tell if a contractor is worth their salt.  I've seen a large number of
body shops in the past six years which tells me that people bid on contracts
without having the requisite expertise in house in hopes of hiring people
along the way.  I know this because the Xerox XTEN project tried three times
hire me for what I regarded as a project which had no hope of succeeding.

I don't think Ed's comments were snobbish.  I think they show a real concern
about how contracts are written.  It's a real problem.  There are too many
people on the Ada bandwagon.  I don't think writing Ada programs are much
harder than other languages, but I do think the class of programs [real-time
embedded systems] working in distributed environments are harder than
your typical FORTRAN simulation or analysis package.  My favorite Ada
example is in Mary Shaw's book: the LaPlace solver for Cm* the 50 processor
multiprocessor [done with Peter Hibbard] based on G. Baudet's PhD thesis.
This six page program is otherwise, basically about 5 lines of FORTRAN
on a uniprocessor [including two CONTINUEs].  It's the class of programs which
are harder.  Writing a spread sheet in Ada and FORTRAN is going to be
about the same difficulty in either language.

Many of the people who read these contracts are just managers and lawyers
and procurement types.  They don't know programming.  They don't understand
the issues of deadlock, debugging, having clear requirements.....
Not all are this way, but many are.  They are concern with crossing T and
dotting i's  [I'm being a bit extreme, sorry, flame off, too long].
EOF

--eugene miya
------