I was going to hold off on this aspect but, John has hit right on the issue,
along
with a prior post somewhat more indirectly.

I would like someone to define what is meant by "lack of Ada engineers".
OK, I will :--)

Clients and shops have become so darn lazy when it comes to "talent
assessment",
they have decided that "keyword matching" defines quality. Now, if I am
hiring an ASIC
h/w design engineer, I probably want someone who has done this before.  But
....

Sorry, but this is a MAJOR pet peeve with me right now. ANYONE who has coded
in
Ada, even for 6 months can come in, and get great money. Why is it, that a
coding
language match has come to define "quality". Ada vs. whatever language is
really not the issue
here. The same goes for C++ or even Java. I will take a GOOD "whatever
language" engineer
who has been experienced in "whatever other" language. How far do I go with
this? Well,
the assessment is qualitative but, if I see someone who is a good
communicator, is
AWARE of implications of design decisions, looks for and sees problems and
hasn't
done a stitch of Ada, I'll take him over an "average engineer" who knows
most of the
Ada syntax and has coded Ada for 5 years; EVERY TIME.

This really gets my goat, because I see engineers every day who are getting
$50+
hour who can't design their way out of a paper bag, because they wrote an
Ada
utility once. Again, keyword matching has replaced real interviewing because
people and organizations are lazy, and in some cases flat out stupid.

If there are any managers out there, frankly, it is time to take back your
organization
from HR departments that have foisted this method of "keyword resume skill
mining" on us all
and those managers within your organizations that hire this way. And if you
do it, then shame on
you.  Why is it that you see some of your best people leave your
organizations? This is
one big reason that I have seen. As much as we all know that salary
comparisons are a
way to put you in an early grave, this issue of keyword matching/quality
assessment of
personnel that has brought crappy engineers in at undeserving rates squeezes
your
quality people and they will only put up with it for so long.

So to answer my question, the only real long-term way to have enough "Ada
engineers"
is to hire "good engineers" and then show them the way. If they are a good
engineer, they
will see the benefits and be some of your best advocates.

IMHO

Joe
> ----------
> From:
> [log in to unmask][SMTP:[log in to unmask]]
> Reply To:     [log in to unmask]
> Sent:         Wednesday, November 17, 1999 6:39 PM
> To:   [log in to unmask]
> Subject:      Re: Ada in the Press
>
> This seems to be a case of everyone agreeing that Ada is by far the best
> choice for high reliability or embedded systems, yet companies (mine
> included) have all but abandoned Ada. I'm starting off on a new design
> that
> is expected to be in service for at least 10 years, but I have been
> forbidden from using Ada for the main reason that the tools are more
> expensive and there is an 'apparent' lack of Ada engineers. There is
> little
> to no input from the DoD customer as to anything other than making full
> use
> of COTS and minimizing the costs. But in this era of a military that is no
> longer 100% MICAP, reliability doesn't seem to be as critical. A concept
> that scares the hell out of me.
>
> I have to choose my battles carefully, but I do point out problems (Ada
> Teaching Moments, as they're known through the engineering department)
> that
> would've been prevented using Ada. The only tactic that I may be able to
> use
> to go to Ada in the future is to show what a  mess it was to do in C++,
> and
> be able to present concrete examples of how Ada would have made it more
> efficient and more reliable.
>
> One problem that I fight continually is the cost of tools. Yes, I know
> full
> well they will pay for themselves in increased productivity but the lack
> of
> hard metrics to prove this to management is a problem. And of course
> company
> and customer management, here and everywhere, consists of many people who
> haven't done any design in years if not decades. They aren't stupid, just
> isolated from important sets of information. Many of the engineers I work
> with agree that Ada is superior, yet the orders flow down from the paneled
> offices that "thou shalt not."
>
> Corporate America (most of it at any rate) is more set on the bottom line
> (only today's of course) and the stock price than in doing a good job. I
> don't know how to change that. The really ironic part of it is the move
> toward VHDL on the hardware side. It makes use of a good number of Ada
> concepts.
>
> I hope that Ada will prevail in the long term, but I think the short term
> will be stressful for all of us who understand its great strengths and
> benefits.
>
> John T Apa
>
> > -----Original Message-----
> > From: Tom Timberlake [SMTP:[log in to unmask]]
> > Sent: Wednesday, November 17, 1999 2:31 PM
> > To:   [log in to unmask]
> > Subject:      Ada in the Press
> >
> > Ada gets a bit of good press in the 11/8/99 issue of Gov't Computer
> News,
> > in an article on Software Development Tools pg 45.
> >
> > "Ada, the required language for most DOD projects from 1991 through
> 1993,
> > is still strongly recommended for embedded systems and other defense
> work.
> > The Information Technology Standards Guidance V3.1, which is still in
> > effect, deprecates the use of C."
> > ...
> > "The same document recommends against C++, stating: 'because the
> mechanics
> > of the C language are embedded in C++, it is susceptible to many of the
> > above noted difficultiew with C ...  Use of C++ for the development of
> > critical systems applications is not recommended.' "
> >
> > The article also lists 9 Ada compiler vendors.
> >
> > ===============
> > Tom Timberlake
> > The Boeing Company
> > Phantom Works Software
> > mailto:[log in to unmask]
> >
> > P.O. Box 3707
> > Mail Stop 4A-25
> > Seattle, WA.  98124-2207
> > USA
>