🚀 go-pugleaf

>  (Real) engineering is based upon certain (perceived to be unmutable) physical 
>laws, such as f = ma.  Basing engineering upon these laws yields methods which
>may be applied, in the same manner, to a set of engineering problems.  For
>instance, calculating the amount of heat loss through the walls of a
>residence is always a fixed relation between given variables, such as:
>wall thickness, insulation used, etc.  Therefore, the solution is always
>arrived at via an accepted mathematical method.

The laws don't change, but I submit that there are at least several
different engineering approaches to any decent problem in any engineering
discipline. Do you use simulation? If so, what kind? Do you use finite
element analysis? CAD? Models? Wind tunnels? etc etc etc. A good engineer
is familiar with the standard tools and techniques, and is able to apply
one or more of them to a particular problem to achieve a proper result.

In what way does software differ from this? The "physical laws" of
software encompass things like the order of a binary search, etc. The
various tools and techniques include OO, functional decomposition,
structured analysis, information modeling, system analysis, etc etc.
A decent software engineer applies such tools and techniques to a
set of requirements to produce a solution.

Seems indistinguishable from any other engineering discipline.

>  To test for competency among engineers, one presents a problem such as
>that outlined above:  how much heat loss through walls with the data below?
>Every compotent engineer will arrive at the same conclusion through (roughly)
>the same methods.

So, for software ask what the space/time behavior of some algorithm is.
Same difference.

>There is no one correct way to write, for instance, a database.

There is no one correct way to design a skyscraper.

>  How does one test a software "engineer" for competency?  In engineering, one
>takes classic problems, changes the important variable values, and asks
>an engineer to solve them.

"Given the following design, adapt it to now work in a distributed
 computing environment. Show all work."

>In software development, there are far fewer 
>classic problems,

Strongly disagree. The problems have been around forever: database,
MIS, real-time, blah blah blah. The sad thing is people keep starting
from a blank sheet of paper every damned time they build anything.

>and, worse yet, none of the problems has one accepted
>mathematical method for solving them.

What is the accepted mathematical method for designing a drawbridge?
There are certainly methods for analyzing stresses, etc. But there is
no cut-and-dried way to just stamp out the drawbridge design. If there
were, we'd design one drawbridge and be done with it for all time.

>Testing for competency among
>software developers is a much more difficult task than testing for 
>competency among (real) engineers.

I do not believe you have supported this claim.

All of the answers I've seen basically boil down to "Software engineering
is not like other engineering disciplines because it is inherently
different". This is just tautology, but I don't believe it for a minute.
There is a cultural belief among many programmers that what they do IS
in some way different from what other engineers do, but that is just
the ego of fragile wannabee "artistes" speaking up. Fundamentally, there
is nothing more or less difficult, more or less creative, more or less
rigorous, more or less amenable to metrics, more or less amenable to
process control, etc etc etc between software and any other engineering
discipline you'd care to name.

Software is just an immature field. And it shows.
--
* The opinions expressed herein are my own, except in the realm of software *
* engineering, in which case I borrowed them from incredibly smart people.  *
*                                                                           *
* Rational: cutting-edge software engineering technology and services.      *