Software Engineering in Florida

Software Engineering in Florida

[Charles H. Sampson]

     I was told several years ago, by someone who should know, that the
Florida legislature had codified the term _engineer_, limiting it to 
practitioners of the classical engineering disciplines.  The upshot was
that anyone who called himself a software engineer was breaking the law.

     I like to mention this in a lecture on software design that I often
give.  Does anyone know if it's still true or has the definition been 
expanded to include software?

                                Charlie

-- 
     To get my correct email address, replace the "claveman" by
"csampson" in my fake (anti-spam) address.

Re: Software Engineering in Florida

[Robert Dewar]

In article <1e0rgtb.6j187t1hibcsaN@[209.132.126.64]>,
  claveman@inetworld.net (Charles H. Sampson) wrote:
>  I like to mention this in a lecture on software design that I
> often give.  Does anyone know if it's still true or has the
> definition been  expanded to include software?

You might also want to investigate the initiative in Texas
to rigorously define "software engineer", in part by requiring
competence in traditional engineering core disciplines (at
least this was the case last time I heard about it, a year
ago).



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Software Engineering in Florida

[Ted Dennison]

In article <1e0rgtb.6j187t1hibcsaN@[209.132.126.64]>,
  claveman@inetworld.net (Charles H. Sampson) wrote:
>      I was told several years ago, by someone who should know, that
> the Florida legislature had codified the term _engineer_, limiting it
> to practitioners of the classical engineering disciplines.  The upshot
> was that anyone who called himself a software engineer was breaking
> the law.
>      I like to mention this in a lecture on software design that I
> often give.  Does anyone know if it's still true or has the definition
> been expanded to include software?

Check out the law yourself at
http://www.leg.state.fl.us/citizen/documents/statutes/StatuteBrowser99/i
ndex.cfm?Mode=Display_Statute&URL=Ch0471/titl0471.htm

From a quick skimming, it looks like you just can't refer to yourself as
a "registered engineer" unless you actually have registered with the
state board. There is language in there that defines what "engineer"
means, but I think that's just for the purposes of interpreting the law,
not a law in and of itself. It just appears to be trying to prevent
people from lying about being registered when they aren't.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Software Engineering in Florida

[Richard Kenner]

In article <7vv26t$tju$1@nnrp1.deja.com> Ted Dennison <dennison@telepath.com> writes:
>From a quick skimming, it looks like you just can't refer to yourself as
>a "registered engineer" unless you actually have registered with the
>state board.

No, there's more than that: 471.003 starts with "No person other than
a duly registered engineer shall practice engineering".  However precisely
because the definition of "engineer" in 471.005(6) does not apply to
software engineering, the entire statute does not refer to us.

Re: Software Engineering in Florida

[Richard D Riehle]

In article <lpdV3.8$C%6.715@typhoon.nyu.edu>,
	kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:

>No, there's more than that: 471.003 starts with "No person other than
>a duly registered engineer shall practice engineering".  However precisely
>because the definition of "engineer" in 471.005(6) does not apply to
>software engineering, the entire statute does not refer to us.

We really need to take more care in our use of the word "engineering"
when discussing software.  I post the following in the form of a
"Devil's advocate," proposition.

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.

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.  

Software engineering is now where Industrial Engineering used to be. 
Most classical engineering, including chemical engineering, are based
on the measurable forces of physics.   Software practice, in
general, is not constrained by those forces.  Every engineering practice
includes some kind of design metrics.  Software practice may proceed
oblivious to any notion of design metrics.  In fact, design metrics
are rarely an issue for most software products.  Without design metrics,
there will never be a discipline we can call software engineering that
is as credible or respectable as other branches of engineering.

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.  

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.  

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 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.

Richard Riehle
http://www.adaworks.com

Re: Software Engineering in Florida

[Ron Skoog]

Richard D Riehle wrote:
> 
> In article <lpdV3.8$C%6.715@typhoon.nyu.edu>,
>         kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:
> 
> >No, there's more than that: 471.003 starts with "No person other than
> >a duly registered engineer shall practice engineering".  However precisely
> >because the definition of "engineer" in 471.005(6) does not apply to
> >software engineering, the entire statute does not refer to us.
> 
> We really need to take more care in our use of the word "engineering"
> when discussing software.  I post the following in the form of a
> "Devil's advocate," proposition.
> 

snip

> 
> Software engineering is now where Industrial Engineering used to be.
> Most classical engineering, including chemical engineering, are based
> on the measurable forces of physics.   Software practice, in
> general, is not constrained by those forces.  Every engineering practice
> includes some kind of design metrics.  Software practice may proceed
> oblivious to any notion of design metrics.  In fact, design metrics
> are rarely an issue for most software products.  Without design metrics,
> there will never be a discipline we can call software engineering that
> is as credible or respectable as other branches of engineering.

The other engineering disciplines also have a sound basis in mathematics
and have sound mathematical models (or approximations) for what they
do.  I have yet to see a CS program that expects 4 years of math (or at
least 3 years of Calculus, which would be less useful than statistics
and discrete math) where the normal Chemistry, Physics, and Engineering
major is looking at that.

> 

snip

> 
> 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 think that you would find a number of these people that could pass the
PE exam (after the normal study.)  The reason I'd say that is the unusal
number of peple programming that are not CS degreed.  I seem to run into
more non-CS degreed people coding than CS degreed people.  In my
experience the Math major made the best programmers (there were too few
people doing actual software engineering to form an opinion as to which
were best.)

This is also a field (using the popular definition) where people with no
degrees (or degrees in English or MDs) are just as likely to write
articles in the popular magazines as people with CS/IS degrees.

You also see a multitude of programming languages and methodologies that
are used based off of the preceived availability of programmers, off the
nearly religious devotion that seems to take over people, or the
availability of shareware/freeware.  In a engineering environment you
would expect these the to be chosen based off of their applicability to
the problem domain and net cost.

> 
> 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.
> 
> Richard Riehle
> http://www.adaworks.com

Ron Skoog

Re: Software Engineering in Florida

[David Starner]

On Mon, 8 Nov 1999 00:35:25 GMT, Ron Skoog <rons@nospam.aonix.com> wrote:
>The other engineering disciplines also have a sound basis in mathematics
>and have sound mathematical models (or approximations) for what they
>do.  I have yet to see a CS program that expects 4 years of math (or at
>least 3 years of Calculus, which would be less useful than statistics
>and discrete math) where the normal Chemistry, Physics, and Engineering
>major is looking at that.

Looking at the degree sheets (here at Oklahoma State) that's not fair.
A CS degree requires Calculus 1 & 2, Linear Algebra, Discrete 1 & 2, 
and Engineering Statistics. 
Biochemistry requires Calculus 1 & 2, or Calculus for Tech Students 1 & 2. 
Physics requires Calculus 1 & 2 and Differential Equations (though
I understand some of the higher class have an unwriten prerequisite
of Vector Calculus.)
Most of the Engineering majors required the same as Physics.
Electrical Engineering required Calc 1 & 2, DiffEq, Linear and
Calculus of Several Variables.

So basically, at least around here, a CS degree requires more math than
the Physics, Chemistry or Engineering major, unless you want to be an EE.
(Also, in practice, many CS majors double major in Math, whereas 
Engineering majors don't have enough time to take another major.

--
David Starner - dstarner98@aasaa.ofe.org

Re: Software Engineering in Florida

[Richard D Riehle]

In article <805aqc$9ic1@news.cis.okstate.edu>,
	dvdeug@x8b4e53cd. (David Starner) wrote:

>Looking at the degree sheets (here at Oklahoma State) that's not fair.
>A CS degree requires Calculus 1 & 2, Linear Algebra, Discrete 1 & 2, 
>and Engineering Statistics. 

All of which are important and reflect the effort of your faculty
to design a solid program.   

   [ snipped some supporting information ]

>So basically, at least around here, a CS degree requires more math than
>the Physics, Chemistry or Engineering major, unless you want to be an EE.
>(Also, in practice, many CS majors double major in Math, whereas 
>Engineering majors don't have enough time to take another major.

But this is still not engineering.  It is excellent preparation for
engineering.  Computer science is not engineering, just as chemistry
and physics is not engineering.  This is what I meant when I suggested
that we need to be careful when categorizing a discipline as engineering.
Perfectly respectable programs with rigorous academic requirements in
math and science may not be engineering programs.  It is certainly true
that many computer science majors will graduate with more mathematics
than some engineering students.  They are still not prepared for taking 
the Professional Engineering exam.  This thread was about the right
to call youself an engineer.  Florida and other states have made it 
clear that you need to pass the PE exam to do so.  Mathematics is not
enough.

Richard Riehle
 

Re: Software Engineering in Florida

[Ron Skoog]

I concur with that.  When & where I got my CS degree there was no
requirements for more than the 2 Calculus courses and one Discrete math
course.  I would have liked to seen another course (or three) in
discrete math.  It is the basis (or at least seems to me to be) for
going on into formal methods.

Where I took Chemistry the listed requirements were close to what you
list (4 semesters of Calculus) but the actual requirements were higher. 
The 1st semester Physics teacher advised anybody without 3 semesters of
Calculus to drop the class.  After that it got worse...  The recommended
math for a chem degree was to add a class in statistical mechanics to
the list of courses.

Ron

Richard D Riehle wrote:
> 
> In article <805aqc$9ic1@news.cis.okstate.edu>,
>         dvdeug@x8b4e53cd. (David Starner) wrote:
> 
> >Looking at the degree sheets (here at Oklahoma State) that's not fair.
> >A CS degree requires Calculus 1 & 2, Linear Algebra, Discrete 1 & 2,
> >and Engineering Statistics.
> 
> All of which are important and reflect the effort of your faculty
> to design a solid program.
> 
>    [ snipped some supporting information ]
> 
> >So basically, at least around here, a CS degree requires more math than
> >the Physics, Chemistry or Engineering major, unless you want to be an EE.
> >(Also, in practice, many CS majors double major in Math, whereas
> >Engineering majors don't have enough time to take another major.
> 
> But this is still not engineering.  It is excellent preparation for
> engineering.  Computer science is not engineering, just as chemistry
> and physics is not engineering.  This is what I meant when I suggested
> that we need to be careful when categorizing a discipline as engineering.
> Perfectly respectable programs with rigorous academic requirements in
> math and science may not be engineering programs.  It is certainly true
> that many computer science majors will graduate with more mathematics
> than some engineering students.  They are still not prepared for taking
> the Professional Engineering exam.  This thread was about the right
> to call youself an engineer.  Florida and other states have made it
> clear that you need to pass the PE exam to do so.  Mathematics is not
> enough.
> 
> Richard Riehle
>

Re: Software Engineering in Florida

[Ron Skoog]

I concur with that.  When & where I got my CS degree there was no
requirements for more than the 2 Calculus courses and one Discrete math
course.  I would have liked to seen another course (or three) in
discrete math.  It is the basis (or at least seems to me to be) for
going on into formal methods.

Where I took Chemistry the listed requirements were close to what you
list (4 semesters of Calculus) but the actual requirements were higher. 
The 1st semester Physics teacher advised anybody without 3 semesters of
Calculus to drop the class.  After that it got worse...  The recommended
math for a chem degree was to add a class in statistical mechanics to
the list of courses.

Ron

Richard D Riehle wrote:
> 
> In article <805aqc$9ic1@news.cis.okstate.edu>,
>         dvdeug@x8b4e53cd. (David Starner) wrote:
> 
> >Looking at the degree sheets (here at Oklahoma State) that's not fair.
> >A CS degree requires Calculus 1 & 2, Linear Algebra, Discrete 1 & 2,
> >and Engineering Statistics.
> 
> All of which are important and reflect the effort of your faculty
> to design a solid program.
> 
>    [ snipped some supporting information ]
> 
> >So basically, at least around here, a CS degree requires more math than
> >the Physics, Chemistry or Engineering major, unless you want to be an EE.
> >(Also, in practice, many CS majors double major in Math, whereas
> >Engineering majors don't have enough time to take another major.
> 
> But this is still not engineering.  It is excellent preparation for
> engineering.  Computer science is not engineering, just as chemistry
> and physics is not engineering.  This is what I meant when I suggested
> that we need to be careful when categorizing a discipline as engineering.
> Perfectly respectable programs with rigorous academic requirements in
> math and science may not be engineering programs.  It is certainly true
> that many computer science majors will graduate with more mathematics
> than some engineering students.  They are still not prepared for taking
> the Professional Engineering exam.  This thread was about the right
> to call youself an engineer.  Florida and other states have made it
> clear that you need to pass the PE exam to do so.  Mathematics is not
> enough.
> 
> Richard Riehle
>

Engineering & Software Engineering

[M.]

Richard D Riehle wrote in message
>Software engineering is now where Industrial Engineering used to be.
>Most classical engineering, including chemical engineering, are based
>on the measurable forces of physics.   Software practice, in
>general, is not constrained by those forces.  Every engineering practice
>includes some kind of design metrics. Software practice may proceed
>oblivious to any notion of design metrics.

I'm in trouble then, because I'm an engineering intern and still oblivous to
"design metrics".  Is there another term for the concept?  Is a data sheet a
set of design metrics?

>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.

A few college CS departments appear to be making progress too.
(Unfortunately, I can't say my alma mater was one of them.)

M.

Re: Engineering & Software Engineering

[Richard D Riehle]

In article <MpqV3.79$4D5.48229@ratbert.tds.net>,
	"M." <me@home.xx> wrote:

>Richard D Riehle wrote in message

>>Every engineering practice
>>includes some kind of design metrics. Software practice may proceed
>>oblivious to any notion of design metrics.
>
>I'm in trouble then, because I'm an engineering intern and still oblivous
to
>"design metrics".  Is there another term for the concept?  

Let's take mechanical engineering as an example.  When one designs
a piece of machinery, it is always designed to some tolerances. You
could say that you design to "snugness of fit."  Even a simple bolt
and nut are specified at the same TPI. A camshaft, a piston, the
compression ratio of your engine, all are measurable.  They all behave
according to the laws of physics.  Coefficient of friction is real.

We can measure the viscosity of liquids and plan for their behavior in
a design.  We can regulate the flow of electricity according to some
published specifications.  Over and over in physical engineering we
can apply what I call "design metrics".  The reason you never see the
term in conventional engineering is that it is inherent in the design
process.  The reason you never see a term like it in software engineering
is that it is almost non-existent.  I say almost because we do have some
opportunities for design metrics but they are rarely used.

So, as an engineering intern, you are using design metrics. It's just
that no one feels it necessary to explicitly use the term.  Who was
it that said, "I was writing prose all my life and didn't even know it."

Richard Riehle
http://www.adaworks.com 

 

Re: Software Engineering in Florida

[Robert Dewar]

In article <804plo$dvs$1@nntp5.atl.mindspring.net>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:
> Is software engineering simply an attractive oxymoron?
                                               ^^^^^^^^

I assume you mean contradiction in terms (I see no possible
interesting literary effect in this particular phrase :-)

> 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.

I disagree, engineering has nothing to do with the state of
development of a discipline, but rather with the *kind* of
discipline. It is clear to me that the activities of building
software are fundamentally similar to other engineering
activities.

> 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.

Well to many people programming means coding, so that is in
fact a useful term, to emphasize that coding is just one
aspect of the total engineering effort.



<We tout Ada as a software engineering language>

I hope not, this is a useless idea, almost as useless as
object oriented programming language :-)

Languages are tools in which you can do many things. Calling
a programming language a software engineering language is
like calling a hammer a "fine furniture building hammer" :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Software Engineering in Florida

[Richard D Riehle]

In article <807202$9if$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>In article <804plo$dvs$1@nntp5.atl.mindspring.net>,
>  Richard D Riehle <laoXhai@ix.netcom.com> wrote:
>> Is software engineering simply an attractive oxymoron?
>
>I assume you mean contradiction in terms (I see no possible
>interesting literary effect in this particular phrase :-)

I have, indeed, used it in its defined sense of "a combination
of contradictory words or terms.  However, since you mention 
literary effect, I am suddenly intrigued by the possibilities. :-)

>I disagree, engineering has nothing to do with the state of
>development of a discipline, but rather with the *kind* of
>discipline. It is clear to me that the activities of building
>software are fundamentally similar to other engineering
>activities.

I always love it when you disagree with me.  Your positions are
always intelligently considered and intellectually challenging.

As to the state of the discipline, when I was a young man growing
up in farm country, we would manufacture temporary tools using
baling wire and other materials at hand.  One could call that
engineering, but most farmers would simply call it "making do."
A huge body of the work that passes for software engineering
product reminds me of the baling wire implements from the farm.
Someone once described software as a "pile of dry rot held up by
a flying buttress."   At some point, the state of the craft does
evolve from baling wire art to engineering.  The place where it
makes its transition is a function of the level of rigor we apply.
That rigor, in engineering, includes a well-known body of design
metrics.  While we have made some progress in design metrics in
software practice, there is a very long way to go before we can
achieve the level already in place for physical engineering.

In an earlier post I mentioned "industrial engineering."  It was a
long time before physical engineers acknowledged the validity of this
branch of engineering.  Many still refuse to take it seriously.  Our
field, software, would probably learn something valuable from the
evolution of industrial engineering to its current place in the
realm of engineering.  

In the physical world we carefully differentiate between architects
and engineers.  We also distinguish between a carpenter and an architect,
a metal worker and an engineer.   With all of the discipline required
for creating a working computer program, and such discipline is
essential as we know from experience, the effort is not that of
engineering.  It is closer to that of an inventor, experimenting with
some interesting ideas until something works.  

I do not want to oversimplify the engineering process.  Many engineering
projects are also characterized by trial and error.  For example, no
one knew that fluting an aluminum would increase its compression
strength by 20 percent.  Once the mathematical properties of fluting 
were studied, we had a model for predictability for other materials.
Such predictability is rare in software practice.  Most programmers
don't even recall the properties of Big O computations.  The use of
metrics in design is practically non-existent.  

I respectfully submit that the state of the practice is an important
criterion for determining whether software development is an engineering
discipline or simply another craft.

>Well to many people programming means coding, so that is in
>fact a useful term, to emphasize that coding is just one
>aspect of the total engineering effort.

Yes.  A draftsperson is someone who renders an engineering design
into a format that can be studied by engineers and builders. The
manufacturing people must be able to interpret the drawing.  But
no one, especially the draftsperson, would call that draftsperson
an engineer.   When we take to calling an Oracle database programmer
an engineer, we are trivializing the term and proving a point
to those who reject software practice as an engineering discipline.

This is why I am saying that we must take care in our use of the term
engineering when referring to software practice.  We need a solid
definition of software engineering, in the context of conventional
engineering, that makes sense.  Pressman, in his widely-used book 
on software engineering goes on for pages and pages before he ever
defines software engineer, and then the definition is not very good.
Sommerville also falls short in this.  If the textbooks we use for
teaching software engineering are unable to define software engineering
in the context of general engineering practice, how can we expect to
be regarded as credible by our brethren in other engineering fields.

><We tout Ada as a software engineering language>
>
>I hope not, this is a useless idea, almost as useless as
>object oriented programming language :-)

Well, you know we agree on this.  Where did I put that left-handed
monkey-wrench, anyway?   :-)

>Languages are tools in which you can do many things. Calling
>a programming language a software engineering language is
>like calling a hammer a "fine furniture building hammer" :-)

Of course, there are many different kinds of hammers.  We do have
tack hammers, ball peen hammers, claw hammers, and, my personal
favorite, the sledge hammer.  I see a programming language as closer
to being a tool box.  A good tool box will have the tools I need 
for solving problems.  I will never forget one of my great lessons
in metrics as a young man working on an automobile engine.  I should
have used a torque wrench and didn't.  The recommende torque for a
particular set of bolts was published.  Like any good programmer,
I simply twisted the top off and drilled out the bolt buried inside
the engine block.  Why would I have wanted to rely on the published
metrics since I could always fix it later?
 
Richard Riehle

Re: Software Engineering in Florida

[Marin Condic]

Richard D Riehle wrote:

>
> In an earlier post I mentioned "industrial engineering."  It was a
> long time before physical engineers acknowledged the validity of this
> branch of engineering.  Many still refuse to take it seriously.  Our
> field, software, would probably learn something valuable from the
> evolution of industrial engineering to its current place in the
> realm of engineering.
>

Industrial Engineers still deal with the physical - the flow of raw materials
through a production process. There is a good deal of real-live math involved
in the study and design of manufacturing processes. However, I'll give you
this: Industrial Engineering comes closer to Software Engineering than other
disciplines in that it seems more concerned with a continuing process rather
than a finished product.

> Such predictability is rare in software practice.  Most programmers
> don't even recall the properties of Big O computations.  The use of
> metrics in design is practically non-existent.
>

That may be because it is seldom of any practical use. Big O is good for
either theoretical analysis of algorithms or for practical optimization of
relatively small chunks of code. Sure, we who deal with hard realtime systems
can and do consider Big O where applicable, but in most cases Big O is
useless to us. And once you get away from hard realtime, your biggest concern
is not how fast the software will run, but if it will run correctly and/or be
delivered on time to the customer. If it runs slow - get a faster computer!
:-)

Metrics in design are practically non-existent, but remember that metrics in
and of themselves are not the point. How do they move the mission forward?
What are the problems faced by the bulk of software practitioners? Is there a
subset of practitioners whos problems could be aided by metrics? Not an easy
question to answer.

I once heard it said that Physics was Applied Mathematics and that
Engineering was Applied Physics. If that is the case, then whatever it is we
do - respected, noble and scientific as it might very well be - it could not
be an Engineering discipline.

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Software Engineering in Florida

[Ehud Lamm]

On Mon, 8 Nov 1999, Robert Dewar wrote:

|<We tout Ada as a software engineering language>
|
|I hope not, this is a useless idea, 

It is indeed dangerous. When I ask students questions that compare (let's
say) Ada95 and Java solutions to a creatin issue, they usually say "well
obviously Ada is better.... This is an Ada course, and the course is
titled 'Ada and Software Engineering'...."

I always tell them that (a) this is not a valid argument in anycase (we
might call this fallacy an "Ad Languagem" instead of "Ad Hominem"... (b)
Many times it is plain wrong and (c) that it is entirly possible, and
worthwhile to study SE issues in C, for example, beacuse the setting is
deifferent, methods are different, and some issues that ARE solved in Ada
must be creatively solved in C. 

An anecdote.(But please don't take this to seriously)
We had a question that asked "What methods can you use in C/Pascal to make
your code more flexible to changes?"
Most students gave the obvious "comments, constants, subroutines" answer.
But one gave me a list of C "tricks" like using "void *", now this may not
be very elegant and generics in Ada are nicer etc. - but it is indeed a
common approach in C. The student received a bonus plus a comment asking
him to make sure he knows the implications of this trick on his systems
reliability etc.

SE is not a language issue - even though languages are tools that can help
or interfere with the production of good software. There is no one-to-one
mapping, and all languages will have SE issues.

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

 

Re: Software Engineering in Florida

[Marin Condic]

Richard D Riehle wrote:

> We really need to take more care in our use of the word "engineering"
> when discussing software.  I post the following in the form of a
> "Devil's advocate," proposition.
>

<snip>

It seems that there are some things common to engineering fields which computer
software does not share. Maybe as a result we should quit trying to call our
field "engineering" and opt for some other moniker: "Logician?" "Designer?"
"Doctor?"

I can think of no field of engineering normally recognized as such which does
not in some way deal with the arrangement of physical matter into some kind of
repeatable patterns to make it do something useful: Mechanical engineers
arrange metal into weapons. Civil engineers arrange concrete into targets.
Chemical engineers arrange molecules into fuel/explosives so that the ME's can
destroy the work of the Civil engineers. Electrical engineers arrange silicon,
etc. to flow electrons which will guide the ME's and Chem E's work to the Civil
E's work.

What physical anything does software arrange into? Software has no physical
reality. It is not some form of matter that is arranged into a useful and
repeatable pattern. (Indeed, if we had such a pattern, we'd never repeat it -
just subroutinize it.) Software is the writing down of rules for solving some
problem. It is as abstract as mathematics. Would we ever refer to a
mathematician as a "Numerical Engineer"? Is there any way we would ever line up
what a mathematician does and say it is very similar to what an ME does except
his medium is numbers instead of metal?

Another - and in my mind, very fundamental - difference between what we
software practitioners do and what "engineers" do is that we never build the
same thing twice. A civil engineer can say "Well, this structure is a
cantilever only it is made out of this new material 'Unobtanium'  which has the
following strength and weight properties, so I can compute the following
equations which will tell me what the dimensions of the cantilever should be to
support the loads expected." There is no equivalent to the "cantilever" in
software practice. If it exists at all, it becomes a reusable component and is
never again repeated. Think of "sort" or "search" as the parallel - if indeed
they are. Once you figure out the algorithm and code/test it, you don't revisit
it the next time you want to sort something. Its not like we have in the field
"Sort" experts as the CE's might have a "Cantilever Bridge" expert who's job it
is to keep redesigning cantilever bridges in a variety of places and using a
variety of materials.

The "engineer" applies a set of historically discovered rules in solving a new,
yet categorizable, problem. The "software practitioner" is in the business of
dreaming up the rules to solve a problem. It seems to me there is something
very different about the two professions.

>
> 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.

Well, I admit I certainly can't resist the opportunity to help you poke around
in that hornet's nest. It can't be any worse than the "free software" debate,
eh? :-)

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Software Engineering in Florida

[tmoran]

>I can think of no field of engineering normally recognized as such which does
>not in some way deal with the arrangement of physical matter into some kind of
  I think this is a red herring.  Society/the Law has no particular
interest in regulating based on whether physical matter is rearranged.
The important thing is the professional's impact on the citizenry.

  Once upon a time there were a lot of "engineers" designing steam
boilers, which blew up entirely too often.  Criminal or civil penalties
on the designer were of scant comfort if many people were killed and
great damage was done.  So legislatures started requiring certain
qualifications of such "engineers" to lessen the problem.  As software
insinuates itself into more and more areas, and the damage done by bad
software starts to appear in large type on front pages, it's reasonable
to expect legislatures will use the same technique as a tool to lessen
the problem.

  Then there's also the "raise wages by limiting the supply" aspect
of such regulations, which potentially applies as much to "software
engineers" as to "professional engineers", doctors, or beauticians.

>Another - and in my mind, very fundamental - difference between what we
>software practitioners do and what "engineers" do is that we never build the
>same thing twice. A civil engineer can say "Well, this structure is a
>...
>Its not like we have in the field "Sort" experts as the CE's might
>have a "Cantilever Bridge" expert ...
  Look at Knuth on sorting.  He does not in fact give a single "sort
algorithm", but shows many, which are optimum in different
circumstances.  An occasional sort of a few thousand short records on a
fast machine may be appropriately handled by whatever sort is most
conveniently available in the library, just as you can bridge a small
ditch with any old plank.  But someone designing an external sort of a
massive, nearly sorted, database, shouldn't rely on that library sort,
but should in fact call on a "Sort" expert, just as the CE's would have
a "Cantilever Bridge" expert.

>The "engineer" applies a set of historically discovered rules in solving a new,
>yet categorizable, problem. The "software practitioner" is in the business of
>dreaming up the rules to solve a problem. It seems to me there is something
>very different about the two professions.
  "Originality is the root of all evil" is perhaps an overstatement,
but a good software practitioner will certainly try to re-use existing,
debugged, code, or at least existing algorithms and data structures,
rather than inventing new ones on the spot.  Ditto for existing
interfaces and APIs as opposed to slightly "improved" ones.  At a
higher level of abstraction, the engineer who wants to create a
transportation system, say, tries to dream up combinations of
historically discovered techniques - bridges of various kinds,
roadways, etc, that will best do the job.  The software practitioner
faced with "design a computer system to let us sell books over the
internet" will dream up combinations of large or small servers, web
page software, databases, etc.  that will best do the job.  Just as the
software practitioner might decide that something unusual - a small,
cheap, specialized wireless ordering computer people can keep on their
bookshelves, say, might be part of the best solution, the engineer
might decide that people-carrying pneumatic tubes would be part of his
best solution.

  When looking at an engineer's work, or a software practitioner's
work, it's a heck of a lot more common in either case to say "yes,
that's a good idea to use such and such for that part", than to say
"good grief - I would never in a million years have thought of that way
of doing things!".

Re: Software Engineering in Florida

[Marin Condic]

tmoran@bix.com wrote:

> >I can think of no field of engineering normally recognized as such which does
> >not in some way deal with the arrangement of physical matter into some kind of
>   I think this is a red herring.  Society/the Law has no particular
> interest in regulating based on whether physical matter is rearranged.
> The important thing is the professional's impact on the citizenry.
>

I think my point was that, despite any possible need for Society/Law to regulate
what we do, that doesn't make us necessarily "engineers". Lawyers, Beauticians,
Doctors, Barbers, and Veterinarians are all regulated by law. That doesn't make what
they do "engineering". And I don't think it needs to be a matter of esteem either.
Doctors are at least as - if not more highly trained than engineers. Doctors make
considerably more money than engineers. Doctors are more respected at country clubs
and social gatherings than are engineers. This does not make doctors "engineers" nor
does it denigrate them to say they are not "engineers".

>
>   Once upon a time there were a lot of "engineers" designing steam
> boilers, which blew up entirely too often.  Criminal or civil penalties
> on the designer were of scant comfort if many people were killed and
> great damage was done.  So legislatures started requiring certain
> qualifications of such "engineers" to lessen the problem.  As software
> insinuates itself into more and more areas, and the damage done by bad
> software starts to appear in large type on front pages, it's reasonable
> to expect legislatures will use the same technique as a tool to lessen
> the problem.
>

Of all the possible professions on the planet, "Politician" has got to be the most
deadly. Even deadlier than "Paid Criminal Assassin" - More deaths have been caused
by Presidents/Kings/Dictators (and other job descriptions) than by all other
professions combined. (And these are the people we want to be in charge of all the
guns? :-) Nobody licenses or regulates politicians. Yet they are the absolute most
deadly and dangerous profession there is.

The fact that you can kill lots of people does not mean that a) you are or should be
regulated or b) that you are by that same fact an "engineer". Maybe software geeks
should be licensed. Maybe not. But what does that have to do with wether or not what
we do should be labeled "engineering"?

>   Look at Knuth on sorting.  He does not in fact give a single "sort
> algorithm", but shows many, which are optimum in different
> circumstances.  An occasional sort of a few thousand short records on a
> fast machine may be appropriately handled by whatever sort is most
> conveniently available in the library, just as you can bridge a small
> ditch with any old plank.  But someone designing an external sort of a
> massive, nearly sorted, database, shouldn't rely on that library sort,
> but should in fact call on a "Sort" expert, just as the CE's would have
> a "Cantilever Bridge" expert.

Well, maybe the "sort" argument is weak - but it still seems fundamentally different
to me than the work done by most engineers. The bulk of what ME's do is redesign the
exact thing over and over again with different optimizations for the different
usages. Software geeks don't generally work in that environment - which is one
reason that what we do is so hard to measure. We seldom design two systems that are
enough alike to make any sort of fair comparison. Sure we attempt to reuse as much
as we can and their are systems where we go through multiple iterations of building
new software based on old software to solve very similar problems (engine control
software comes to mind! ;-) and to that extent what we do starts looking more like
"engineering" because we can apply rules and build on a body of knowledge about the
particular problem domain.

But while I like holding the title "Engineer" - I'm not sure that maybe we don't
have more in comon with Mathematicians or perhaps Political Scientists. Or perhaps
our discipline can't be correlated to what someone else does and we just have to
stick to calling ourselves "Computer Scientists" and work to make the profession as
respected as any other. I've watched the software world try for a long time to make
itself into "Software Engineering" but I'm beginning to become convinced that maybe
we're really something new & unique and not just a branch on the "Engineering" tree.

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Software Engineering in Florida

[tmoran]

>what we do, that doesn't make us necessarily "engineers". Lawyers, Beauticians,
  Sorry, I thought the discussion was about licensing.  If it's about
naming, then, as one who has done pretty much the same thing while
being name "programmer", "systems analyst", and now "software engineer",
I'll continue letting other folks call me whatever they want.

> Nobody licenses or regulates politicians. Yet they are the absolute most
"X is licensed for reason Y" doesn't imply that Z, to whom reason Y
also applies, should/will be licensed.  Not to mention the practical
difficulties of having the incumbents write the rules for who can
replace them, or "thwarting the will of the people" if some unusually
bad candidate was elected, but not allowed to take office.

Re: Software Engineering in Florida

[Robert I. Eachus]

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...

Re: Software Engineering in Florida

[M.]

Robert I. Eachus wrote in message <3828A2D7.F23C91AE@mitre.org>...
>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.

Electrical engineering can't be taught in classrooms without appropriate
design projects on the side (and I mean _design_ projects, with engineering
notebooks and design documentation.  Not "turn in a circuit/program that
works.").  Is this what you mean?

>> 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,

You can be considered one, and even call yourself one if you are an employee
of a company.  But in some states you can't do business directly with the
public as an "engineer" unless you have qualified for and passed the exam.
(By the way, I am not a lawyer, and these are not professional legal
opinions.)

>  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.

I think this is completely unnecessary, not only because it is too
restrictive, but also because it's necessarily vague on the qualifications
for a "masterpiece."  Furthermore, I think professional societies for
software (esp. the IEEE CS) are underutilized.

M.

Re: Software Engineering in Florida

[Marin Condic]

"M." wrote:

> You can be considered one, and even call yourself one if you are an employee
> of a company.  But in some states you can't do business directly with the
> public as an "engineer" unless you have qualified for and passed the exam.
> (By the way, I am not a lawyer, and these are not professional legal
> opinions.)
>

The last time I checked, this was a free country and you are pretty much
entitled to call yourself anything you like so long as there is no intent to
defraud the public. You can call yourself "Grand Imperial Poobah Of The
Waterbuffalo Lodge" or "Doctor Telefunken UB48" or even just "The Dude" if you
like. (Or "Your Dudeness", if you are not into the whole brevity thing.) The
problem comes in when you start representing to the public (generally involving
commercial transactions)  that you are competent to do something for which you
are not qualified. (Think of medical doctors vs PhDs. Both go by the title
"Doctor" but only one attempts to practice medicine.)

BTW: My legal opinions are worth what you pay for them. :-)
--
Marin David Condic, Software Engineer.
(Out of the way, you swine! An Engineer is coming!)
-----------------------------
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Software Engineering in Florida

[Robert Dewar]

In article <3829C229.6694381D@pwfl.com>,
  condicma@pwflcom wrote:
> The last time I checked, this was a free country and you are
> pretty much entitled to call yourself anything you like so
> long as there is no intent to defraud the public.

Well I guess I agree that your legal opinions are worth what
we pay for them. You might wish this to be so, but it is
definitely NOT true. There are many counter examples where
you are not allowed to use a professional title without being
licensed by the state.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Software Engineering in Florida

[Robert Dewar]

In article <80dk6i$4ms$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> Well I guess I agree that your legal opinions are worth what
> we pay for them.

oops, I really meant to put in a couple of smileys there, sorry
Marin!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Software Engineering in Florida

[Marin Condic]

Robert Dewar wrote:

> we pay for them. You might wish this to be so, but it is
> definitely NOT true. There are many counter examples where
> you are not allowed to use a professional title without being
> licensed by the state.

Well, you notice that I did say "pretty much" - there are always
exceptions. But as I pointed out, you can call yourself Doctor Dewar and
that's fine up until you attempt to do so to convince someone you can
(legally) remove their appendix. If I were making out a check to you and
asked you how you wanted it made out, you could say "Make it payable to
Poindexter Schwartz" and it would be quite legal to cash it so long as
there is no intent to defraud.

Obviously, using the name "Officer Odie" in conjunction with a badge is
illegal. I'd have no reason to think that if I opened up shop under the
name "Marin Condic - Civil Engineer" and proposed to build bridges for
you, that the law might not take umbrage at this. I'd expect to see the
real Officer Odie show up and perhaps take me to see a judge somewhere.
The common thread in all that is that there is some attempt to defraud
the public, which is always illegal even if the specific instance is not
spelled out in statute.

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Software Engineering in Florida

[Robert I. Eachus]

"M." wrote:
 
> Electrical engineering can't be taught in classrooms without appropriate
> design projects on the side (and I mean _design_ projects, with engineering
> notebooks and design documentation.  Not "turn in a circuit/program that
> works.").  Is this what you mean?

    Yes, electronic engineering can easily be taught in a laboratory. 
But for power engineering, another facet of electrical engineering it is
difficult or next to impossible.  The diciplines used to be separate,
and have separate professional societies the IRE and the IEE.  My father
was a member of both, and worked on the merger.   For example, you
really have to get out into the "real world" and manage a power grid to
understand the emergent properties that occur with a large, complex,
geographically distributed system.  Similarly, software engineering is
heavily involved in the emergent properties of large and complex
software systems.  At RPI there were great industrial resources nearby
that allowed graduate students (in both software and power engineering)
to get the necessary experience outside the school.  Worcester
Polytechnic Institute also has a software engineering work-study program
that is well regarded around here. 
 
> You can be considered one, and even call yourself one if you are an employee
> of a company.  But in some states you can't do business directly with the
> public as an "engineer" unless you have qualified for and passed the exam.
> (By the way, I am not a lawyer, and these are not professional legal
> opinions.)

   Correct--they are not professional legal opinions.  I am not a lawyer
either, and the rules vary significantly from state to state.  Generally
calling yourself a Professional or Registered Engineer without a license
is bad juju, and signing drawings as an engineer can get you lots of
liability and occasionally jail time unless you are a PE or have a PE
signature on the drawings too.  But most states do provide for
unlicensed engineers to call themselves engineers without passing the
whole PE exam.  If the requirements were otherwise, it would be a Catch
22, you couldn't qualify for the experience requirements.
  
> I think this is completely unnecessary, not only because it is too
> restrictive, but also because it's necessarily vague on the qualifications
> for a "masterpiece."  Furthermore, I think professional societies for
> software (esp. the IEEE CS) are underutilized.

    Both the ACM and the IEEE CS have consistantly wimped out on the
licensing and professionalism issues. A genuine software engineering
professional society will have to be a different entity.  This doesn't
rule out IEEE or even ACM involvement, but it would have to be a new
group with different membership.   This does not mean that there is not
a major need for what ACM and IEEE CS do provide their members, just
that they are not professional organizations, and dumping a substantial
fraction of their membership will never happen.

-- 

                                        Robert I. Eachus

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

Re: Software Engineering in Florida

[Robert Dewar]

In article <3828A2D7.F23C91AE@mitre.org>,
  "Robert I. Eachus" <eachus@mitre.org> wrote:
     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.

I disagree with the above, unless you are using programming
to mean coding.

For me programming = the entire process required to create
a program, and most certainly one aspect of programming is
software engineering (another is requirements engineering).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Software Engineering in Florida

[Robert I. Eachus]

Robert Dewar wrote:
  
> I disagree with the above, unless you are using programming
> to mean coding.

  I think we are in agreement.  Programming begins after low-level
design is complete.  But I still use coding to apply only to writing in
assembler or machine code.  In an Ada context, library unit
specifications should be an output of the design process, while bodies
and subunits are part of programming.
 
> For me programming = the entire process required to create
> a program, and most certainly one aspect of programming is
> software engineering (another is requirements engineering).

   I see it the other way around.  Software Engineering includes the
entire process from concept to deployment.  Programmers need not be
software engineers, but software engineers must be familar with the
entire process, including requirements analysis, human factors, user
interfaces, system architecture, software design, programming, testing,
and (gasp!) documentation.  The software engineer's role is to
compromise between all these areas to get the best possible product
within budget and schedule.

-- 

                                        Robert I. Eachus

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

Re: Software Engineering in Florida

[David Botton]

I'd like to know for sure, I live there. Please keep us posted.

David Botton

Charles H. Sampson wrote in message
<1e0rgtb.6j187t1hibcsaN@[209.132.126.64]>...
>     I was told several years ago, by someone who should know, that the
>Florida legislature had codified the term _engineer_, limiting it to
>practitioners of the classical engineering disciplines.

Re: Software Engineering in Florida

[M.]

David Botton wrote in message <7vvkcb$2fc8$1@news.gate.net>...
>I'd like to know for sure, I live there. Please keep us posted.

Then you can contact the state engineer registration authority and ask them
;)

M.

Re: Software Engineering in Florida

[Richard Kenner]

In article <UTPU3.578$2t5.387319@ratbert.tds.net> "M." <me@home.xx> writes:
>David Botton wrote in message <7vvkcb$2fc8$1@news.gate.net>...
>>I'd like to know for sure, I live there. Please keep us posted.
>
>Then you can contact the state engineer registration authority and ask them
>;)

There shouldn't be a smiley there.  If somebody *needs* to know what
the law is (as opposed to merely being curious), they should contact a
lawyer.  The interpretation of statutes by people posting in
comp.lang.ada is not legal advice and should not be construed as such.

A friend of mine once pointed out in a discussion of visa requirements
in rec.travel that people should always check with official sources:
you can't go to a border and say "somebody in rec.travel said I didn't
need a visa".

Re: Software Engineering in Florida

[Richard Kenner]

In article <1e0rgtb.6j187t1hibcsaN@[209.132.126.64]> claveman@inetworld.net (Charles H. Sampson) writes:
>I was told several years ago, by someone who should know, that the
>Florida legislature had codified the term _engineer_, limiting it to 
>practitioners of the classical engineering disciplines.  The upshot was
>that anyone who called himself a software engineer was breaking the law.
>
>I like to mention this in a lecture on software design that I often
>give.  Does anyone know if it's still true or has the definition been 
>expanded to include software?

It's not that straightforward.  You're talking about Section 471.  For
the text of the definition subsection, see

http://www.leg.state.fl.us/citizen/documents/statutes/StatuteBrowser99/index.cfm?mode=Display_Statute&Search_String=&URL=Ch0471/SEC005.HTM

Basically, it says you are not allowed to use the title of "registered
engineer" unless you are certified.  It also says that you can't
represent yourself as an "engineer" unless you are certified.  *But*
the definition of "engineer" is precisely that in that section (which
I agree does not include software engineering).

However what that means is not what you state.  Indeed, it's almost
the exactly opposite.  It is certainly perfectly legal in Florida to
call oneself a "software engineer".  Indeed, if software *were*
included in 471.005(6), you could *not* do that without being a
licensed "software engineer".

Re: Software Engineering in Florida

[Robert I. Eachus]

Richard Kenner wrote:
 
> Basically, it says you are not allowed to use the title of "registered
> engineer" unless you are certified.  It also says that you can't
> represent yourself as an "engineer" unless you are certified.  *But*
> the definition of "engineer" is precisely that in that section (which
> I agree does not include software engineering).
> 
> However what that means is not what you state.  Indeed, it's almost
> the exactly opposite.  It is certainly perfectly legal in Florida to
> call oneself a "software engineer".  Indeed, if software *were*
> included in 471.005(6), you could *not* do that without being a
> licensed "software engineer".

  Actually, I the more important argument goes to 471.003(2)(c):

> (2)  The following persons are not required to register under the provisions
> of ss. 471.001-471.037 as a registered engineer:... 
 
>  (c)  Regular full-time employees of a corporation not engaged in the
>  practice of engineering as such, whose practice of engineering for such
>  corporation is limited to the design or fabrication of manufactured products
>  and servicing of such products.

   This, or the equivalent laws in other states, have been the laws
cited when
lawsuits involving software and someone called a "software engineer"
were resolved.  This has been important.  Take for example, a liscensed
EE who writes software with a job title of Software Engineer.  Do the
laws on professional responsibility, and conversly limiting liability
apply?  No, because software engineering is currently not a field where
those laws apply.  We desparately need a category of safety-critical
software to be covered under such laws, if not that particular law.  The
title might even be "Safety Engineer" or "System Engineer", but the goal
is to get certain classes of products subject to both the portions of
the law which are proactive (i.e. those laws that try to prevent
dangerous products from existing) and well as the parts which protect
the designer if he complies with the proactive part of the law.

-- 

                                        Robert I. Eachus

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

Re: Software Engineering in Florida

[Richard Kenner]

In article <3828ACA7.7B376431@mitre.org> "Robert I. Eachus" <eachus@mitre.org> writes:
>  Actually, I the more important argument goes to 471.003(2)(c):

I did too, the first time I read it, but on a closer reading, I no
longer saw that as key.

>>  (c)  Regular full-time employees of a corporation not engaged in the
>>  practice of engineering as such, whose practice of engineering for such
>>  corporation is limited to the design or fabrication of manufactured
>>  products and servicing of such products.

This is somewhat ambiguous, but I'm taking the "whose" to mean the
*employee* since I think that's the most clear meaning.

I'm having trouble understanding the point of this paragraph, but the issue
as I see it is that it only applies when the corporation is *not* doing
"engineering", but the person is.  In the software engineering case, neither
the person *nor* the corporation would be doing "engineering" according
to the definition of the law, and so that paraghraph would not apply.

This seems to cover a situation, say, wher a company is providing some
product, like a toaster, and hires an electrical engineer to help
design them.  This paragraph seems to imply that person need not be
a registered engineer, but I don't see why that should be the case.

Engineering Liability (was Re: Software Engineering in Florida)

[Robert I. Eachus]

Richard Kenner wrote:
 
> This seems to cover a situation, say, wher a company is providing some
> product, like a toaster, and hires an electrical engineer to help
> design them.

   Correct.  If the company is not involved in the provision of
engineering services as defined by this section, but produces products,
then any engineers working on those products need not be licensed.

>  This paragraph seems to imply that person need not be
> a registered engineer, but I don't see why that should be the case.

   Let me give you an example of why this is.  Say that you work for
Acme Bolt Company, and you are asked to design some new bolts.  (More
often, you are developing a new process for creating standard bolts.)  A
skyscraper is built by Bravo Construction using your bolts, and it
collapses during construction due to a severe storm.  You--and Acme Bolt
company--are not liable.  The engineer who signed off on the engineering
drawings may be, and if he didn't test the bolts to insure that they met
his requirements, he may be guilty of negligence.

   On the other hand, say that the engineer did test the original bolts,
and Acme Bolt switched during construction to providing the new bolts
knowing that they were unsuitable for this use.  Now Acme Bolt is
liable, under the implied warranty of merchantability, and is liable for
consequential damages.  You, however, again are not liable as long as
you did not conceal information from Acme Bolt.  (For example, you
tested the bolts and found that the breaking stress was 5% lower than
the previous design.  Unless you deliberately concealed this information
from your employer, you have no liability, and no responsibility to tell
Bravo Construction.)

   I have been involved in a couple of legal cases substantially similar
to the latter.  The purchase orders from Bravo (in the example above)
specified the breaking stress, and Acme Bolt switched products to one
that did not meet the spec in the middle of a large order.  Both
suppliers settled quickly once it turned out in depositions that the
implied warranty law applied.  There is no way to void or limit such an
implied warranty that the product is suitable for the intended use.  And
the vendor is liable for consequential damages, including those that
have not yet been incurred.  In other words, whether they win or lose
the lawsuit, they are still potentially liable for unlimited damages. 
Under those circumstances, any publicly traded company is forced to
settle before their next financial statement is issued.

   Remember the Pentium divide bug?  Once it was shown that Intel knew
about the bug and still shipped chips containing it, I can imagine their
lawyers and accountants making it clear in no uncertain terms, that they
had to get those chips out of circulation now! 
 
-- 

                                        Robert I. Eachus

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