Re: Software Engineering in Florida

[tmoran@bix.com]

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