[NTLUG:Discuss] Re: software engineer? -- Technicians don't understand what Engineers do

[Bryan J. Smith]

From: Greg Edwards <greg at nas-inet.com>
> Bryan,
> I agree with you about the overuse of the title Software Engineer. 
> However, your reasons are way off the reality of what a Software 
> Engineer really is.

I disagree.

> The business community has used the title Software Engineer as a method 
> to promote staff and justify pay grades as opposed to ability and 
> knowledge.  A Software Engineer is allot more than a programmer who has 
> gained enough time in the job to earn a raise and more responsibility. 
> I'm not trying to belittle or take light of anyone that has gained the 
> title this way, so don't flame me for the comment.

I disagree with their usage _entirely_.

> Try as hard as they might the traditional Engineering bodies do not 
> understand or grasp the true breadth of what a Software Engineer is and 
> what they bring to the table.  Software Engineering does not fit the 
> mold of most Engineering disciplines.

I disagree _entirely_.

Just because the common perception in the IT world is that a "Software
Engineer" does not need to research law, apply risk analysis or use
numerical analysis does not mean it _should_ happen.

At the same time, you do _not_ need to do such things for "most software
development tasks."  That's why there is confusion.

There is the _same_ perception in the civil or mechanical engineering
worlds.

KEY POINT:  What programmers don't understand about Software Engineering
is why they don't understand the distinction.

> I agree that most Engineering disciplines are trained and experienced in 
> applying theory and standard design methods to a static set of blue 
> prints and construction plans.  Most Civil Engineers couldn't lay a pipe 
> at the designed grade to save their lives.

Same deal with software engineers.  Many do not know how to use a lot of
software themselves!

> Unlike other Engineering disciplines a Software Engineer has to 
> understand and be able to implement the entire software life cycle. 

That's not true at all.  Civil and mechanical engineers _are_
responsible for the _entire_life_ of a product!  Just because the
construction workers or iron workers don't does _not_ mean the engineers
are not!

Again, you _fail_ to understand the _entire_ range "Software
Engineering" encompasses.  It's more than just "life cycle."  It's law,
it's economics, it risk, etc...

No, you don't have to use it for most of the project out there, just
like you don't have to have Civil or Mechanical engineers designing a
_lot_ of things.

I mean, when a company has landscaping done, does it hire a civil
engineer?  No!

> Software is allot more than designing it, coding it, and releasing it.

And _more_ than you realize too.  Same deal with civil, mechanical,
etc...

> When the whole concept of project teams for all software projects got 
> hot and heavy (starting in the late 80's) the use of the title Software 
> Engineer vs the Software Engineering discipline muddied the waters. 
> Instead of someone that was a Software Engineer using the title, 
> programmers that had enough experience and education started being 
> called Software Engineers.

It's worse than that.

Again, refer back to my "Engineer - Technologist - Technician"
distinction.  What you describe about "life cycle" is more of a
"Technologist" viewpoint.

> Look at the roles on a project team:
> Project manager - scheduling, budget, staffing, and oversite
> Project designer - analysis, data and process flow, system integration 
> analysis, interactive presentation analysis and design
> Programmer - coding, data layout and structure, API definitions and 
> implementation

The Project Manager/Designer is the same.  There is a lead and then the
others that are basically the lead without the leaders.

But then you _fail_ to separate the "Developer" (Technologist) from the
"Programmer" (Technician).

> Technical writer - product definitions, project specifications, test 
> plans, training manuals, user guides, installation guides

Hey, we could thrown in a "Computer Scientist" as the replacement for
the "Physicist" as well.  But we're not, because it's _overkill_ for 98%
of projects.

> System administrator/technician - deployment, upgrade, technology 
> installation and configuration, and technology interoperability

More "Technician" level, but on the "Eletrical" side of things.

> Test engineer - unit and integration test planning, regression testing, 
> test case analysis

More "Technician" level, but on the "Testing" side of things.

Now you _know_ what I mean by "less non-practical" engineers to "more
practical" technicians.

> Every one of these  people are a specialist within their own right. 
> Where Software Engineering as a discipline differs from other industries 
> is that a Software Engineer knows all of these specialities and can 
> apply them.

Not true at all!

Electrical Engineers who design semiconductors know not only the
physics, but the technical applpicatino.  They may not be as
"knowledgeable" at the technical level as a technician, but they _can_
understand it.

You can_not_ go back in reverse.

Do you understand economics or risk analysis at a calculus-level of
application?  Do you know the underlying software code laws of your
locale?

Are you willing to be held _criminally_negligent_ for not knowing so?

> To compare a Software Engineer to a Civil Engineer is the 
> wrong analogy.

No, it's the 100% _right_ analogy.

Because people like yourself try to act like it is not, that's why it
takes _so_long_ for new Engineering disciplines to be recognized.

> A Software Engineer would be better compared to the 
> differences in the medical profession where the GP is the Software 
> Engineer and the Surgeon is the Programmer.

No, not at all.

LITMUS TEST:  Look that the "liability."

GPs, Surgeons, etc... are _all_ equivalent to Engineers.  They are
licensed and held criminally liable.

Nurses are the Technologists.  They understand some of the actual
application of medicine _better_ than the doctors.  They can be (and are
typically) licensed as well, but not at the same level.  In the same
regard, technologists _can_ and _are_ licensed by BoPEs.

In fact, my #1 complaint is that state BoPEs need to "get off their
duff" and start licensing IT Professionals at the "Technologist level!" 
Make them _liable_ for malpractice!

When you make people accountable, it solves the problem overnight! 
Especially for power plants, financial systems, etc...

CASE STUDY:  SOMEONE'S ASS SHOULD HAVE BEEN ON-THE-LINE FOR WHAT THE
HELL HAPPENED OUT AT OHIO'S PROGRESS ENERGY!

But because the state BoPE's continue to fight "back and forth" with
people like yourself, people like _me_ get "drowned out."

> However, the educational and experience requirements are reversed
> because a surgeon needs to know general medicine while a programmer
> does not need to know Full Life Cycle Methodology.

But is _more_ than just "full life cycle methodology."
That's the point I can't prove to you.

You keep looking at the "lower technical aspects" because you do not
appreciate the higher science and social ones.

> To use an analogy from traditional engineering disciplines between 
> engineers and technicians is like comparing apples and oranges.

But you forgot the pears in the "Technologists" in between.

IMHO, "Technologists" are the "best of all worlds."

They are the "elite" of knowledgeable technicians, the most "practical"
of designers who know the products _better_ than the engineers who
designed them, while not getting caught up in all the "egghead science"
and "social aspects" that engineers do.

Do you see my point?

No offense, but I hold a BS in Electrical Engineers with a Computer
Architecture / Software specialty, and a minor in Computer Science, from
an ABET accredited BS Electrical and Computer Engineer (BSECE) program
that ranks in the top 25 for EE departments by the College Board.

I have studied many aspects of "Software Engineering" -- let alone
_engineering_ in general.  We're talking Engineering analysis,
Statistics**, Economics, Risk Analysis, etc...

[ **NOTE:  One of the reasons for the original Shuttle Disaster was
because NON-Engineers were in charge of making a _lot_ of decisions that
Engineers and Statisticians found afterwards.  Changes were made at
NASA.  The recent Shuttle Disaster was due to environmental policy -- I
know, I saw it _first_hand_ (short answer:  They need to go back to
styrofoam because the replacement crap almost _destroyed_ an Army
missile I helped develop back in 1998). ]

Engineering is _not_ technology.  It is _not_ application of technology,
but application of _science_ -- both physical _and_ social.  It is the
"study of how our manmade world is created."

If you want a "pure technology engineering" approach, the former Soviet
Union is a _perfect_ example.  You could get a BS in Ball Bearings.  You
got *0* Engineering principles we had in the US.  And the result was
_excellent_ products when they worked, but _catastrophic_ failures when
they didn't.

Engineering is _science_ of both the physical _and_ social aspects.  It
is _not_ technology.

But that's why the British decided that 7-8 years of theory and 1-2
years of internship did _not_ expose the engineer to enough _technology_
they were supposed to design.  So that's why they changed it from the
old Roman-French approach.


-- 
 Discussing distributions is like discussing political parties.
Not only do they enflame people, but they often break down into
sets of blind assumptions.  Instead, people should focus on the
   specific details of underlying technologies, just like one
should when it comes to specific terms in legislation.  Because
the similarities are often more surprising than the differences.
----------------------------------------------------------------
Bryan J. Smith, E.I.                          b.j.smith at ieee.org