[prog] State of software engineering profession

[Robert J. Hansen]

> 	How did we, as software professionals, get into a state that
> 	accept poor software as a normal way of life.

And as I've said, I don't accept the premises upon which your question
is based.  In order for your question to be meaningful, several
conditions must all be true:

1.  We, as software professionals, must accept poor software as a normal
way of life.  You as a software professional may, but I certainly don't,
and I've never worked with anyone who has accepted lousy, bug-ridden
software as a way of life.  Lousy, bug-ridden software is a permanent
burr in my backside, as it is for pretty much every other programmer I
know.  (I've worked with Management which hasn't cared about lousy,
bug-ridden software... but that's not a software engineering problem,
that's a Managerial problem.)

2.  We must have had better software in the past, otherwise there's no
state to "get into".  We didn't get into this state: we've ALWAYS been
in this state.  Most quality control procedures in the industry are
desperate attempts to get out of this state, which also contradicts your
first premise--if we accepted poor software, we wouldn't spend so much,
economically and academically/intellectually, into getting out of this
state.

3.  We must be software professionals.  The sad fact is, most of us
aren't.  I've had coworkers on large-scale software engineering projects
who were 20 years old, no college CS experience, no formal CS
education--or other coworkers who were Perl gurus, who'd never touched a
C compiler before in their lives, who were suddenly given a 50,000-line
C codebase and told to fix a bug a customer reported.  This is not the
behavior of a responsible, professional industry.  (Randy was a software
professional in every sense of the word; but Management, in their
infinite wisdom, was having him work _far_ outside his professional
specialty, which is inherently unprofessional.)

Professional engineers have certain obligations by law.  If Management
tells a civil engineer, "you've got to have that bridge designed by
tomorrow so it can be built by Wednesday", the civil engineer is
required by law to tell their boss "I can't do it safely, and I refuse
to adhere to your unsafe schedule."  If the boss fires them, then the
engineer can take the matter and the firing to a professional board, or
else to court.

Good Lord, if any of us tried to do that to Management when they wanted
the impossible by next Tuesday, we'd be fired in a heartbeat.  To a
large degree, the industry is set up in a way as to make sure we never
get the chance to elevate programming to software engineering, because
Management will never allow us to say "no".

So I can't accept your question, nor can I give it a meaningful answer. 
It's predicated on three things which, in my professional experience,
are simply not true.

We aren't accepting the lousy state of software; we didn't "get into
this state", we've always been in this state; and in my more cynical
days, I think the field is totally unworthy of the term "software
engineering".

-- 
Robert J. Hansen <rjh at sixdemonbag.org>