LISTSERV mailing list manager LISTSERV 16.0

Help for TEAM-ADA Archives


TEAM-ADA Archives

TEAM-ADA Archives


TEAM-ADA@LISTSERV.ACM.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEAM-ADA Home

TEAM-ADA Home

TEAM-ADA  November 1999

TEAM-ADA November 1999

Subject:

Keyword hiring Was: RE: Ada in the Press

From:

"Wisniewski, Joseph (UNKNOWN)" <[log in to unmask]>

Reply-To:

Wisniewski, Joseph (UNKNOWN)

Date:

Wed, 17 Nov 1999 20:59:58 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (157 lines)

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
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2017
November 2017
October 2017
September 2017
June 2017
May 2017
April 2017
January 2017
December 2016
November 2016
October 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
December 2010
November 2010
October 2010
September 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
June 2007
May 2007
March 2007
February 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996

ATOM RSS1 RSS2



LISTSERV.ACM.ORG

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager