"a rose by any other name would smell as sweet"
-willie the shake

The title "Engineer" has a specific, legal meaning.  Professional use of the Engineer title requires rigorous education, testing, internship and licensure.  None of these exist for professional programmers.  Therefore, there are no Professional Software Engineers, regardless of what is on our business cards[1].  All of this also applies to the "Architect" title.  Architects have similar education and testing requirements to Engineers, and like Engineers they must be licensed to practice professionally.  Use of the Engineer and Architect titles for computer specialists is nothing more than aggrandizement.

In my book, your exemplar "good software engineer" is really a good programmer, and your "good programmer" is anything but good.  He is terrible.  He'll write "correct", "clean" code that will be five to ten times slower than the good programmers' painstakingly optimized code.  Then he'll go and rewrite their code to "clean it up" to match his own and check it in without telling anyone.  Then the next release candidate suffers catastrophic performance problems and a mad scramble to figure out why ensues.  Someone at a previous job of mine did this, and the senior management was not amused.  Bad programmer, no biscuit.

Rant off.

[1] My title at my last gig was "Senior Systems Engineer".  I hated that title and I hate putting it on my resume because it is a lie.  I'm no Engineer.

--Rich P.

Guy Gold

Engineers, like doctors, are licensed professionals.  They are held to codified standards of practice and ethics.  Like doctors, if they violate those standards then they lose their licenses to practice.  This is a fundamental difference between a "software engineer" and a Professional Engineer.  Programmers typically are not held to any standards other than those set by their employers, and those typically revolve around meeting deadlines rather than things like safety and ethics.  Meeting a deadline is more important than ensuring that a program won't flake out and kill someone.

I think this is a problem.  I think that Software Engineers should join the ranks of Professional Engineering professions and that they should be trained and tested and licensed the same as other Professional Engineers.  And just like other Professional Engineers they should be held to codified standards of practice and ethics that trump corporate policies and release schedules.

No, I don't expect every programmer to be a Software Engineer, no more than I expect every construction worker to be a Civil Engineer.  That'd be crazy -- and nothing would ever get built.  As long as we have a need for real Software Engineers we will have a need for skilled programmers to "build" the software that they design.

--Rich P.

Imagine a highway or building or train or airliner being designed and constructed to the same standards that these SCADA systems were made.  Take it another step: imagine medical equipment designed the same way that these SCADA systems were.  Now be afraid because medical equipment really is designed the same.

It gets worse: that medical equipment can't be updated.  They can't be updated because changing anything will push them off spec, will violate whatever EAL the devices have, and will make them legally unusable for medical practice.  Many of these are running old operating systems -- like Windows 98 old -- without any patches at all.  And yet, we trust quite literally our lives to these things.

--Rich P.

You need both, you need guys who will build you a highway but engineers come in all forms and there a number of them built on more theoretical grounds who don't need a license to do their jobs, and will likely spend a lot of time writing code, pencils on paper, etc...

If you have a rant on poor programming, rant on that, but engineering comes in a lot of forms, let's not forget that....

- Jared

________________________________
 From: Richard Pieri <richard.pi...@gmail.com>
To: BLU Discuss <disc...@blu.org>
Sent: Saturday, January 21, 2012 9:05 PM
Subject: Re: [Discuss] Programming vs Engineering

Case in point, this article that just came down through Slashdot:
http://www.digitalbond.com/2012/01/19/project-basecamp-at-s4/

Imagine a highway or building or train or airliner being designed and constructed to the same standards that these SCADA systems were made.  Take it another step: imagine medical equipment designed the same way that these SCADA systems were.  Now be afraid because medical equipment really is designed the same.

It gets worse: that medical equipment can't be updated.  They can't be updated because changing anything will push them off spec, will violate whatever EAL the devices have, and will make them legally unusable for medical practice.  Many of these are running old operating systems -- like Windows 98 old -- without any patches at all.  And yet, we trust quite literally our lives to these things.

--Rich P.

I'm sorry, I just don't accept the made-up rule (I will note that this
isn't the first time I've been lectured on not being a PE) that says the
word "Engineer" is off limits unless you've passed a PE test.  Go ahead,
be mad about it.  Get indignant about it.  I don't really care.  I'm a
Software Engineer.  Most of the world agrees with me.

You want to say that PEs have rigorous standards?  Fine, I won't argue.
 I don't put "Professional Engineer" on my business cards.  I know what
it means.  But you have to realize that you've just taken two common
language words that describe me, and said "you can't use those
together".  How should I describe myself and my job without those words?
 Does that mean I'm an amateur?  I'm an engineer for my day job,
therefore I am a professional engineer.  There, I didn't make it in to a
proper noun.  Does that make you happy?

The bottom line is that engineering is a discipline. That means in terms
of code, that the code works when you throw it over the fence, that it
is also readable and maintainable. It also means that you don't rewrite
code for the sake of it. I've had to work with many very old programs
(like Lex and YACC) where the code was originally written by a graduate
student. But, both programs work. I've seen many rewrites of old code
that never were able to perform as well as the old code. Another
discipline is to document both using comments, as well as reasonable
comments when checking in to a source code control system like git, SVN,
or CVS. Recently at work there was a question of why my code (BASH in
this case) pointed at a specific server. I went back to the git logs and
found when that was changed. (I know it is not a good practice to hard
code things like that, but this was originally designed as a way to make
it easier for people in the office to install a piece of software we
bought from Europe).

What is the standard language in which to write programs?
What is the standard operating system that is run on computers?
If we can't have a standard operating system, what is the standard API
to which we code?
Who owns these things? Would you pay Microsoft for the privilege to
practice in your field?

In some ways we are to blame. We software engineers have not taken our
profession seriously. We have not created and/or joined the professional
organizations, like doctors, lawyers, electricians, and pipe-fitters, to
define and protect our profession.

What has happened, sadly, is that we have a profession in which there
are no standards and any newbe can come along create a new programming
language because he or she did not like the existing language. If we are
lucky, it looks something like previous languages, but this is not
always the case. We don't steadily improve the tools of our craft, we
destroy them and rebuild them new each and every time.

How many programming languages and environments are needed? How many
operating systems? If you look at electricians, they have a whole set of
regulations about wire, connectors, methodologies, etc. Do we? Hell, if
we compared ourselves to plumbers, we would re-invent the pipe for each
job.

--Rich P.

We do need both -- all three, actually.  We need scientists to do the hard research, to create new materials and such.  We need engineers to take the scientists' research and create blueprints for new, better things.  And we need skilled laborers and craftsmen to implement those blueprints.  I see similar distinctions in software: scientists who do that research, engineers who turn the research into plans, and programmers who write code to those plans.

Mark is right: the software industry keeps reinventing itself.  This is both good and bad.  Most of us wouldn't be in our current lines of work if it didn't, but at the same time it means that we get shoddily designed SCADA systems and medical devices, ATMs and voting machines vulnerable to all sorts of compromise, and so forth.  I think that holding PSEs' work to the same kinds of standards that we hold other PEs' work would go a long way towards preventing this kind of crap software from being released as product.

I'm not suggesting that PSEs would be required to use only certain languages or operating systems.  A Civil Engineer can use whatever materials he wants when designing a building or a bridge.  Likewise, a Software Engineer can use whatever "materials" he wants when designing a program.  What is important is that the bridge meets defined standards of safety and reliability.  Likewise, it is important that the program meets appropriately defined standards.

--Rich P.

IMHO, the terms 'software engineer' and 'software architect' should be
banned, and replaced with the
'old school' terms of programmers and analysts.

There is noting wrong with the old terms, but by making the 'new
titles' sound like licensed professionals,
it just cheapens both the professional terms, and the professions of
software professionals.

I'm at the end of my career, so it is no skin off my back.  But I am
proud to be a programmer, an
analyst, and sysadmin at different parts of my careers.

HR puts some artificial terms on many 'professional titles', but they
too are part of the problem.
Human Resources are just like 'Toilet Resource Providers'.  They used
to be called
'Personnel Departments' before the more dehumanizing 'Human Resources'
title became
popular after someone read one to many management studies from the
Harvard MBA diploma mill.
At the same time, shorter term perspectives became popular in
management (what have you
done for me this quarter), became the norm.  Human Resources, IMHO, was a way to
systematically remove any human element from management decisions.  It
may be better
for the short term bottom line, but long term, I think society
(including the investors) loose.

Somehow, common sense isn't so common anymore.

Well, I suspect that most dictionary makers would say that  Massachusetts  is
defining "professional engineer", not "engineer" (or "professional" ;-).

An ongoing semi-problem that dictionary makers have always had is that people
routinely  try to use them as authorities for what a word *should* mean.  The
actual function of a dictionary isn't to decide what words mean,  but  rather
to  tell the reader how a word *may* be used.  So they routinely include most
of the "wrong" uses of words, sometimes marking them as variant or  slang  or
dialectal or obsolete or whatever.  This is to provide a service for a person
who may not speak the language too well, or  has  run  across  a  word  in  a
context where it doesn't make sense. So you pull out your dictionary, look it
up, and expect to find an entry that in effect says "X can mean  ...,  or  it
can  mean ..., or sometimes it even means ...".  Purists might object to some
of the uses, but dictionary makers aren't trying to provide reinforcement for
the  purists'  views.   They're trying to tell their readers how words may be
used, so that users can make sense of a usage that they've run across.

Larger dictionaries often give definitions for phrases.  I  wonder  how  many
unabridged  dictionaries  define  the  phrase  "professional engineer".  That
definition should include "licensed" (perhaps preceded by "usually" ;-).

We don't expect mechanics to know how to design a supertanker.  We don't expect electricians to know how to design a power grid.  We don't expect bricklayers to know how to design a skyscraper.  But programmers -- people who's expertise is writing code -- are expected to design programs.  Or, to turn that around, people who's expertise is designing programs are expected to spend more time writing code than getting the design right.  I think that this is a major factor in why so many applications, especially embedded applications, are such wrecks.

--Rich P.

I know people who meet all these requirements, and are actively bad as
engineers.  One of them had his PE certification.

None of the half dozen products he had a key engineering role in during the
time I knew him ever shipped.

If you want other engineers to take these certifications seriously, you
need to not give 'em to guys like this.  More importantly, you need to find
a way to give the certification to the really good engineers out there.  As
long as you have tens of thousands of guys out there who are better
engineers than the PE's I have met, I'm going to hire based on skill,
certification be damned.

For that matter, I'll hire based on skill regardless.  Certifications are
perhaps handy filters for people in HR who don't know enough engineering to
filter in other ways.  If you hire based on certifications (or degrees)
blindly, you'll be sinking your own ship.  I've known too many PhD's who
were useless for anything outside academia.  (That bitterness you hear is
the echo of the sound of me cleaning up after a couple of them over and
over again until management FINALLY realized they were the problem.)

On the other hand, one of the best engineers I know fought her way up from
being a tech with an associate's degree.

I do know a couple of PE's who are good engineers, but the best engineers
I've known have not been.

    "To promote the Progress of Science and useful Arts, by securing for
    limited Times to Authors and Inventors the exclusive Right to their
    respective Writings and Discoveries."

Copyright is one form of license.  It gives the Federal government the
power to decide who can and who cannot copy a work.  U.S. Copyright
originally lasted 14 years with an option of a one-time renewal if the
author was still alive at the end of the first 14 years.
http://en.wikipedia.org/wiki/Copyright_Act_of_1790.  Today, as a result
of Disney corporation buying off Congress, the Mickey Mouse Protection
Act of 1998 has extended that 28 years to *120 years*, but only if the
work is by a corporation.  Human beings get only 70 years.  
(http://en.wikipedia.org/wiki/Copyright_Term_Extension_Act)  Copyright
no longer serves "To promote the Progress of Science and useful Arts".  
As Duke University Law Professor James Boyle has pointed out, "We are
the first generation to deny our own culture to ourselves.
<https://twitter.com/#%21/thepublicdomain/statuses/3179288729> ... No
work created during your lifetime will, without conscious action by its
creator, become available for you to build upon.
<https://twitter.com/#%21/thepublicdomain/statuses/3179305900>"

But let's get back to professional licenses.  The argument for why
government should be able to control who can and who cannot practice a
particular profession is that they're supposedly protecting the public
from incompetents.  If a doctor, a lawyer, an electrician, or an
architect screws up, people may well die!  Of course, in practice,
licensing boards more often than not protect their own and incompetent
practitioners generally keep their licenses as long as they don't piss
off anyone on the licensing board.  So the licensing system doesn't even
accomplish what it claims to.

Add to that the fact that no politician can resist the temptation to
control other people's lives in order to pander to powerful lobbying
groups.  As a result of such pandering to organizations like N.O.W.,
state laws all across the country suspend or revoke men's professional
licenses if they fall behind on their child support payments.  
(http://www.ncsl.org/issues-research/human-services/archive-license-re...)  
Not only do these laws have nothing to do with protecting the public
from harm or death if in the course of his profession the practitioner
does something stupid, they also make no sense whatsoever WRT
financially supporting children.  If a man can't keep up with his child
support payments, taking away his ability to make a living, and thereby
guaranteeing that he won't be able to make the payments, makes no
sense.  I know of professional men who've never done anything wrong, but
now have a prison record because they lost their licenses and were
thrown in jail for being too poor to pay their child support.  But from
a politician's perspective, giving a well-funded a lobbying group
whatever they ask for keeps that politician in office.  The result is
that we have reinstituted debtors prison in the U.S. under another name.

So, when you're arguing that we software engineers should be required to
be licensed by the state in order to practice our profession, ask
yourself this: "Do you really want to hand over the power to determine
whether or not you're allowed to work in your profession to shills like
Lamar Smith?"  Smith is the Representative in the House who's been
promoting SOPA, which gives politicians, who couldn't design or
implement a distributed database of name to IP address mappings to save
their lives, the power to take a sledgehammer to the carefully crafted
DNS protocol, thereby destroying the interoperability that makes the
Internet the Internet, and in doing so, spitting on Jon Postel's grave!

This is not to say that I don't think there's a problem of bad code
getting out into the world. Over the course of many decades I've
encountered more than my share of sloppy software engineers.  But I have
to say that only about half of the ones I've encountered were sloppy by
nature.  The other half didn't want to code that way, but bad managers
who pressured them to meet impossible deadlines gave them the choice of
losing their jobs or hacking stuff together as quickly as possible
without proper design at the front end and proper testing at the back end.

I don't have a solution to the problem, but I do know that government
licensing of software engineers will not solve the problem, and will
actually make things worse.

    Mark Rosenthal
    m...@arlsoft.com <mailto:m...@arlsoft.com>

On 1/22/2012 1:55 PM, Drew Van Zandt wrote:

Language Trivia time is over now; thank you for reading.

The interesting bit to me is:

 -Tom

Dating back well before the invention of Software Engineers we had
Mechanical Engineers, Electrical Engineers, and Chemical Engineers, all
of whom were not licensed as Professional Engineers, unless they elected
to do so.

The "engineer" title is largely a reflection of education, but as
Matthew Gillen pointed out, the definition is more broad and anyone who
practices engineering can have the title applied.

Where you draw the line between technician or tradesperson and engineer
is a matter of convention within each industry.

I'll agree that the software field probably should have a "software
technician" title (perhaps it is "software developer", or "programmer",
as someone else mentioned), and some better understood guidelines for
what distinguishes it from a "software engineer." You don't, however,
need a government issued license to make that distinction.

We do have a whole litany of certifications available. If you dismiss
the validity/value of such certifications, what makes you believe that a
single industry administered test will prove more accurate at qualifying
software developers as being of Professional Engineer quality?

 -Tom