Re: Software Engineering in Florida

["Robert I. Eachus" <eachus@mitre.org>]

Richard D Riehle wrote:
 
> Is software engineering simply an attractive oxymoron?  One of my
> degrees is in software engineering, and I am still not sure there
> is such as thing as "engineering" when speaking of software.  It
> seems to be, rather, an emerging discipline with more to emerge
> before we can really call it engineering.

   1) There is an emerging discipline of software engineering.

   2) Software engineering is more closely related to systems
engineering than to       any other engineering discipline.

   3) Good software engineers need to program to stay familiar with
      current best practice.  But software engineering as such has
little or             nothing to do with programming.

   4) If we get to the point of having a PE test for software engineers,
      which might be a good idea, it should have NOTHING to do with any
      academic course of study.  Software Engineering and programming
are both       crafts, but in the case of programming some classroom
time is helpful
      if not necessary.  But the one thing I have seen demonstrated over
and
      over in the past twenty years is that software engineering cannot
be
      taught in classrooms.  

      I took a very good graduate course in Software Engineering at RPI,
and I       learned a lot.  But fellow students who not had relevant
real world       experience were very lost and most dropped the course.

      For example, one assignment was to write a FORTRAN program to do
some             simple text operation on files, I think it was to
convert from upper case
      to mixed case.  The trick was that the same source file had to
compile and             run on an IBM 370 using FORTRAN F, and on a
Prime 550 using Fortran 77.  I             was the only one to submit a
working program that did not test for the             hardware model and
have basically two different implementations that
      both compiled on either system.  
  
> What is the difference between the effort of a methodical programmer
> and a software engineer.  Here is Silicon Valley, every programmer is
> now calling himself/herself a software engineer.  The term has lost
> any meaning it may have had.

  The difference is that the software engineer is concerned about the
total system from lust to dust, while the programmer is concerned with
developing software to solve the problem in front of him.  I've done
both, and there are
times when one or the other is more appropriate, but they are very
different tasks.  In fact, when I was in compiler development I used to
have two styles of programming.  With one, which I used when working on
the compiler, I expected to have very few bugs, and for the code to work
right forever once checked in--or at least until the requirements
changed.  In the other mode of programming, I was disappointed if I
didn't average at least one bug per twenty lines.  (Compiler bug that
is.)  My favorite example:

   with Text_IO; use Ascii;
   procedure Hello is begin Text_IO.Put_Line("Hello World" &
Exclamation); end;

   I don't think I found an Ada implementations in the late 1983 to
early 1984 time frame--including the one I was working on--which got
that right the first time.  Several required more than one fix.  (Note:
In Ada83, the use clause for ASCII was illegal, in Ada95 for reasons
involving child packages, it is not.  And yes, GNAT gets it wrong
issuing two error messages, but I consider this program to be a
pathology.  Someone else can submit the bug report if they want.)
 
> Software cannot be called engineering simply because we organize projects
> around a set of accepted methods of development and project management. It
> cannot be called engineering because we are doing difficult embedded
> projects with it.  It cannot be called engineering because some of us
> who practice have engineering degrees of one kind or another.

   But it can be called engineering if I can examine a project and
decide, on a sound basis that it is never going to work correctly, or
that parts are too brittle to deploy and need to be cleaned up before
fielding, or that the budget is unrealistic early enough to avoid
starting a project that is guarenteed to fail.  However, I am very
frustrated by the fact that experimentation in the area of software
engineering is so difficult.  Here at MITRE we see enough data to be
able to reason from it.  However, in most cases, the data is proprietary
and/or classified, so it is very difficult to publish in this area. 
Hmmm, maybe enough time has passed that I can get permission to publish
the REACT Software Engineering Exercise and the conclusions.  It was a
wonderful eye opener, especially for some of the participants.

> We need to define what we mean by engineering.  The definition must be
> consistent with that for other engineering disciplines.  Although the
> pursuit of an engineering model for software practice is commendable, we
> have not yet arrived at a place where we can honestly elevate what we
> do to the level of engineering.
 
> Having said what I just said, I do see some software practice that comes
> very close to engineering.  Some practitioners do have a realization of
> the importance of design metrics and use those few actually available.
> Some practitioners do build models before commiting to code.  We are
> moving in the direction of tools and languages that can lead to the
> codification of engineering standards.  Some organizations are trying
> to take an engineering approach to the development of software.  Not
> enough.  Sadly, many of those who refer to themselves as software
> engineers have not concept of engineering.  One dBASEIV/FoxPro programmer
> of my acquaintance has the temerity to call himself a software
> engineer.   Texas and Florida may be on the right track here.

  Amen.  There is no reason for your acquaintance to call himself
anything but
a programmer.  Incidently, the reason that most programmer jobs are
titled as software engineers can be laid to the US Department of Labor. 
Once upon a time, there were Systems Analysts, Programmers, and Coders. 
The programmers did the flowcharting, and the SAs did what we would
currently call the software engineer's job, or maybe the software
architect's.  In any case, programmers were considered to be non-exempt
personnel.  Of course today, the job the programmers do has changed
drastically--when was the last time you saw a flowcharting template? 
But the title shift has become part of the language.  Incidently, once
upon a time, about 15 years ago, Ed Bedard did try to get some sort of
professional organization started.  I think most of us decided that then
was too soon.
 
> How many people who call themselves software engineers could pass the
> Professional Engineers exam?  How many reading this message?  That is
> the criteria by which one is allowed to add the initials, PE, to a
> business card or letterhead.  If one cannot pass the PE exam, one is
> not, by commonly accepted standards, an engineer.

  I'd guess very few, but many if not most of those reading this message
probably qualify.  However, your last statement is incorrect.  You can
be considered an engineer without taking the PE exam, in fact one of the
requirements is that you have two years of practical experience.  And I
would hate to have a set of criteria for a PE test in software
engineering that didn't require at least that much practical experience.
 
> I realize I have probably opened a hornet's nest with this, but it is
> important enough for Ada practitioners to consider since we so often
> tout Ada as a software engineering language.

  It is an old hornet's nest, but it's time has come again.  I
personnally think that what is needed is a guild of sofware engineering,
rather than a professional society, and that when I retire the worldmay
be ready for one.

  Why a guild?  Because independent of any PE exam, the real proof of a
programmer or software engineer is in their products.  There has been a
lot of software published in this newgroup that should qualify as
journeypieces.  Masterworks tend to be of a size that they are published
on the web or as parts (or all) of commercial products, but I suspect
that a majority of the readers of this group can point to masterworks
they created.  If we can create a Software Engineering Guild, I think
that the requirements to be a Master should include both a PE test and a
work judged to be a masterwork.

  To make things clear, there are parts of gnat that are programming
masterworks or algorithmic masterworks, but gnat as a whole qualifies as
a software engineering masterwork for those involved in creating and
maintaining the design and development process.  A software engineering
guild should recognize all these  different types of masters, and others
besides.  (And then you need a title for those who are masters in
several areas, but of course we already have it: guru.)

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...