[comp.object] Software "Engineers"

dmg@ssc-vax.uucp (David M Geary) (04/16/91)

]]  ?
]   Jim Showalter

]] Every working definition of "engineering" appears to exclude computer
]] science.

] Is this something to be PROUD of?  As it statnds, it is certainly an
] accurate reflection of the current state of affairs, but hardly a good
] thing.

  Well, I don't know.  There are *sanitation* engineers, but I don't think
I would want to be catagorized with them ;-).

  I have a degree in mechanical engineering, and 7 years experience as 
a "software engineer".  I have always thought that the term software
engineer was somewhat of a misnomer.  As a matter of fact, "engineer" is
one of the most mistreated words in the English language.  Consider that
an "engineer" may be one of the following:

1)  Garbage man.
2)  Someone who rides a train.
3)  Programmer. 
4)  Real engineer.

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

  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.

  Computer science is not, really.  Where is the "science" in computer science?
There is no one correct way to write, for instance, a database.  Developing
software is much more of an art, and less of a science than engineering.
As a matter of fact, that is why I *like* software development more than
engineering.  You get to be more creative.

  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.  In software development, there are far fewer 
classic problems, and, worse yet, none of the problems has one accepted
mathematical method for solving them.  Testing for competency among
software developers is a much more difficult task than testing for 
competency among (real) engineers.
  

dan@ece.arizona.edu (Dan Filiberti) (04/16/91)

A couple of definitions: (from Webster's of course)

engineering - the application of science and math by which the
	properties of matter and the sources of energy in nature
	are made useful to man in structures, machines, products,
	systems, and processes.

science - knowledge obtained through study or practice (many 
	more defs)


What you are talking about is natural science...

"Software engineering" then would be defined as:  the application of
knowledge obtained through study or practice of writing software.  
I have no problem with that, why does everybody else?



		Daniel Filiberti
		dan@helios.ece.arizona.edu [:)}

dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (04/16/91)

In <3844@ssc-bee.ssc-vax.UUCP> dmg@ssc-vax.uucp (David M Geary) writes:

>Computer science is not, really.  Where is the "science" in computer science?
>There is no one correct way to write, for instance, a database.

Computer science is essentially the study of algorithms.  This is why
it is a science.

Algorithms can be implemented in many ways, and each of them is either
correct.

The science in computer science is mostly about correctness.  The
engineering in software engineering is mostly about efficiency.

So:

There may be more than one correct way to write a database system, but
each of them is either correct or incorrect.  The correct ways
will all take forever to implement.

The computer scientist can tell you (or die trying) whether the system
is correct or not.  The software engineer can tell you (or die trying)
how close to correct it can be and still be implemented in your
lifetime.
--
Rahul Dhesi <dhesi@cirrus.COM>
UUCP:  oliveb!cirrusl!dhesi

diamond@jit345.swstokyo.dec.com (Norman Diamond) (04/16/91)

In article <3844@ssc-bee.ssc-vax.UUCP> dmg@ssc-vax.uucp (David M Geary) writes:

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

That is science, not engineering.  Engineering would give answers to questions
such as "How thick should we make the wall, given that we have this list of
constraints and that list of wishes?"

>  Computer science is not, really.  Where is the "science" in computer science?

The traditional science is in things like automata and formal language
theory.  This has led engineers to use context-free grammars (as PART
of their toolkits).  More modern science can include things like what
kinds of design tend to yield higher error rates than what others.
(If you consider anthropology, biology, etc., non-sciences, then you
may object to this one too.)

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

Correct.  This is engineering, just like choosing the bit-width of a bus.

>In software development, there are far fewer classic problems

Yes, because it's newer.  Once upon a time there were no classic problems
in chemical engineering, but chemical engineering is engineering.
--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.

gessel@cs.swarthmore.edu (Daniel Mark Gessel) (04/16/91)

In <1991Apr15.230909@ece.arizona.edu> dan@ece.arizona.edu (Dan Filiberti) writes:

>A couple of definitions: (from Webster's of course)

>engineering - the application of science and math by which the
>	properties of matter and the sources of energy in nature
>	are made useful to man in structures, machines, products,
>	systems, and processes.

>science - knowledge obtained through study or practice (many 
>	more defs)


>What you are talking about is natural science...

>"Software engineering" then would be defined as:  the application of
>knowledge obtained through study or practice of writing software.  
>I have no problem with that, why does everybody else?



>		Daniel Filiberti
>		dan@helios.ece.arizona.edu [:)}

C'mon man! You're being rational! Where's the opinionated opinions?
The emoted emotions? The "I'm right so you're wrong!" at the end?

Seriously, using a dictionary to define terms! You gotta be kidding. . .

:-)

Dan
-- 
Daniel Mark Gessel
Internet: gessel@cs.swarthmore.edu

rick@tetrauk.UUCP (Rick Jones) (04/17/91)

In article <3056@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>
> [...]
>
>The science in computer science is mostly about correctness.  The
>engineering in software engineering is mostly about efficiency.
						     ^^^^^^^^^^
Who says?  I am trying to apply an "engineering" approach to producing business
software (which doesn't always get very stringent criteria attached to it).  My
main concern is reliability and general robustness;  efficiency cannot be
ignored, but it's not the prime issue.

In civil engineering, for example, the most important issue is that the bridge
doesn't collapse.  The equivalent to efficiency is using the minimum material,
but shaving safety margins is a dangerous game!

I would rather define computer science as dealing with correctness of behaviour
under predictable conditions.  Engineering is more about reasonable behaviour
under unpredictable conditions.
-- 
Rick Jones, Tetra Ltd.  Maidenhead, Berks, UK
rick@tetrauk.uucp

Any fool can provide a solution - the problem is to understand the problem

derek@sun4dts.dts.ine.philips.nl (derek) (04/17/91)

I am a technical author - specifically, my job title is Senior Software
Author, in as much as I try to make the stuff you guys write understandable
for Joe Public. So far so good, however in German, the title is:
Beschreibungs Ingeniur = Description Engineer, and in French:
redacteur (technique) = (technical editor)

In the German term, an equal STATUS is implied to highly-qualified senior
(as-you-define "real") engineers.

In the French term a STATUS similar to a clerk is implied. (It is very
difficult, therefore, to get good French technical authors.)

Do I need to state my case? - "engineer" implies status - and I think you 
will find that the WHOLE business is nothing to do with science or 
technology, but with job-status and financial rewards.

Best Regards, Derek Carr
DEREK@DTS.INE.PHILIPS.NL           Philips I&E TQV-5 Eindhoven, The Netherlands 
Standard Disclaimers apply.

zweig@cs.uiuc.edu (Johnny Zweig) (04/18/91)

When they build buildings (an operation widely regarded to be better
understood and practiced than writing software) there are two kinds of people
involved.  "Architects" design how the thing should look, what the overall
geometry of the thing ought to be given its intended uses, and so forth.
"Engineers" take these plans and apply analyses (most of which, contrary to
popular belief, are not anywhere near as "scientific" as f=ma; it is often
rules of thumb like "I need x inches of reinforced conrete to hold up y tons
of building" which are derived from experience) to make sure the thing won't
fall down.

It has long seemed to me that the problem with the term "software engineering"
is that it is often (totally incorrectly) used to describe writing programs. A
software system is a great big (gigantic, in terms of complexity and what can
go wrong, when compared to a measly skyscraper with most of its floors like
the other ones, etc.) thing that needs engineering, architecture, marketing
(for some pieces of software), psychology (this is a pet peeve of mine: there
are a lot of rightly-named "brain-damaged" pieces of software that don't
interact with human brains well -- this includes UNIX utilities with horrid
user interfaces even horridder than most UNIX utilities, and most of the setup
and configuration tools I can think of like PrintMonitor on the Mac) and all
sorts of other things to make it work.  There are parts that need the trained
eye of the artist, others that need to be solid and correct and checked out by
an engineer properly equipped to make the analysis and design/implementation
decisions necessary to keep the thing from being poor.

I think programmers and software engineers and software quality control
experts and managers are all different beasts.  They each need to know how the
others work (in some companies, they find it helpful to rotate people through
various positions so they gain the requisite experience to understand each
other's work) and be able to guide it toward the goal of coming up with good
software.  Just because people misuse the term in confusing ways, and because
none of them have more than about fifty years of experience to go by as the
basis for their engineering expertise, is no reason to say that there is no
such thing as a Software Engineer.  There aren't Teleportation Engineers yet,
because there aren't teleporters.  Software is a new thing (and no I won't
listen to you if you say that software was invented with the Jacquard Loom; I
am talking about nontrivially large software systems). It will be awhile
before software engineering is on the same footing as mechanical engineering.
But it will happen. It has to.

-Johnny Soft

philbo@dhw68k.cts.com (Phil Lindsay) (04/18/91)

In article <3844@ssc-bee.ssc-vax.UUCP> dmg@ssc-vax.uucp (David M Geary) writes:
>  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.  In software development, there are far fewer 
>classic problems, and, worse yet, none of the problems has one accepted
>mathematical method for solving them.  Testing for competency among
>software developers is a much more difficult task than testing for 
>competency among (real) engineers.

The only test I can think of is the GRE, but thats mostly math... And
all the issues of good software development are hardly touched (if at all).
Concepts and methodologies are not mature enough to warrant mass
appeal.  We have many years to go before "engineering" can truly come
close to computer science. 
Right now (from what I have seen) SOFTWARE ENGINEER = EGO.
-- 
Phil Lindsay - "Patents threaten future technology"
Internet: philbo@dhw68k.cts.com  Phone: Wrk7143852311 Hm7142891201
UUCP:     {spsd,zardox,felix}!dhw68k!philbo
USMAIL: 152A S. Cross Creek Rd, Orange, Ca. 92669

jls@rutabaga.Rational.COM (Jim Showalter) (04/18/91)

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

philbo@dhw68k.cts.com (Phil Lindsay) (04/19/91)

In article <1991Apr15.230909@ece.arizona.edu> dan@ece.arizona.edu (Dan Filiberti) writes:
>"Software engineering" then would be defined as:  the application of
>knowledge obtained through study or practice of writing software.  
>I have no problem with that, why does everybody else?

I don't have a "problem" with a literal definition.  In the context of
the industries perception of "Engineering," the words "Software Engineering" 
are misused. 
Computer Science has created all tools to build software, but we have not
figured out an effective way to use these tools.  Most engineering
disciplines have mastered concepts, tools and methods.
-- 
Phil Lindsay - "Patents threaten future technology"
Internet: philbo@dhw68k.cts.com  Phone: Wrk7143852311 Hm7142891201
UUCP:     {spsd,zardox,felix}!dhw68k!philbo
USMAIL: 152A S. Cross Creek Rd, Orange, Ca. 92669

jor@odgate.odesta.com (Jor Bratko) (04/19/91)

In article <1991Apr15.230909@ece.arizona.edu> dan@ece.arizona.edu (Dan Filiberti) writes:
>A couple of definitions: (from Webster's of course)
>
>engineering - the application of science and math by which the
>	properties of matter and the sources of energy in nature
>	are made useful to man in structures, machines, products,
>	systems, and processes.
>
>science - knowledge obtained through study or practice (many 
>	more defs)

>What you are talking about is natural science...
>
>"Software engineering" then would be defined as:  the application of
>knowledge obtained through study or practice of writing software.  
>I have no problem with that, why does everybody else?

>		Daniel Filiberti
>		dan@helios.ece.arizona.edu [:)}

This is great!!!

Now I can say that whenever I'm programming, I'm software engineering!
I am writing software, have been for years, that is to say, I've practiced.
Well... you could argue as to whether I've actually gained any knowledge,
or applied it (you'd have to ask my boss :-).

The above paragraph was just to illustrate a problem that can arise from
such a definition. You end up being able to call any programming
"software engineering". It's just a matter of whether it's
_good_ software engineering or not. So is software engineering any different
than programming? Does it help to have both terms mean the same thing?

There are good points to this definition, too (IMHO). It depends on how it's
interpretted. It's good that all programmers can participate in 
"software engineering". I want to become a better team member in my development
team. I want to gain skills and knowledge beyond what I can figure out on my
own. Thinking of myself as a software engineer helps me have this attitude.
My subjective association is that an engineer is one who recognizes that
relying on knowledge/systems that others have researched and developed is
a very powerful thing.

In the midst of Pressmans latest: "Making Software Engineering Happen",
Jor

---
"This sig was made by hand."
Jor Bratko                          Odesta Corporation, Northbrook, IL
...!mcdchg!ecgcurly!odgate!jor      - Until odesta.com gets registered.
ecgcurly!odgate!jor@mcdchg.uucp     - From the Internet.

guido@cwi.nl (Guido van Rossum) (04/22/91)

dmg@ssc-vax.uucp (David M Geary) writes:

>There is no one correct way to write, for instance, a database.  Developing
>software is much more of an art, and less of a science than engineering.
>As a matter of fact, that is why I *like* software development more than
>engineering.  You get to be more creative.

Uhm, I thought engineers were the people who built bridges, and from
looking around I can only conclude that there is not one correct way
to build a bridge, either.

You get the sense of being more creative when developing software
because computers are more flexible than steel and concrete.

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"Many of my best friends are lumberjacks and only a few of them are
transvestites"

mikeb@inset.UUCP (Mike Banahan) (04/23/91)

Well, I'm not going to get sucked into this debate at length, despite
that fact that I have some very strong views on it (I have been / am
an engineer of both hardware and software for years).

Let me just quote Henry Ford at you: "An engineer can design for ten cents
what any damn fool can do for a Dollar".

He may have something there ...



-- 
Mike Banahan, Founder Director, The Instruction Set Ltd.
mikeb@inset.co.uk

dan@ece.arizona.edu (Dan Filiberti) (04/24/91)

In article <1991Apr19.152242.8822@odgate.odesta.com>,
jor@odgate.odesta.com (Jor Bratko) writes:

>"Software engineering" then would be defined as:  the application of
>knowledge obtained through study or practice of writing software.  
>I have no problem with that, why does everybody else?

This is great!!!

Now I can say that whenever I'm programming, I'm software engineering!
I am writing software, have been for years, that is to say, I've
practiced.
Well... you could argue as to whether I've actually gained any
knowledge,
or applied it (you'd have to ask my boss :-).

The above paragraph was just to illustrate a problem that can arise
from
such a definition. You end up being able to call any programming
"software engineering".

--------------------------------

Interesting point.  I'm glad that you grasped what I am trying to say.
Ultimately, seeing the words "software engineer" on a business card
isn't going to convince anyone of the quality of your work.

By the way, it is absolutely true that if you are programming using
techniques that you have learned, you are "software engineering".
But, does that make you a "software engineer" in someone else's
eyes?

I can design my own shed, and build it, but am I a "civil engineer"?
I guess maybe its the quality and quantity of knowledge that really
counts. IMHO.


			Daniel Filiberti
			dan@helios.ece.arizona.edu [:)}

---------------

diamond@jit533.swstokyo.dec.com (Norman Diamond) (04/26/91)

In article <1652@inset.UUCP> mikeb@inset.co.uk (Mike Banahan) writes:

>Let me just quote Henry Ford at you: "An engineer can design for ten cents
>what any damn fool can do for a Dollar".

An engineer can also design for a Dollar what a damn fool can never do.
Some engineers can also design for Ten Dollars what a damn fool cannot
even understand.  This is why the damn fools don't let engineers do
engineering (in one field of engineering, anyway).
--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.

dc@sci.UUCP (D. C. Sessions) (04/27/91)

In article <1652@inset.UUCP> mikeb@inset.co.uk (Mike Banahan) writes:
# Well, I'm not going to get sucked into this debate at length, despite
# that fact that I have some very strong views on it (I have been / am
# an engineer of both hardware and software for years).

  Me too.

# Let me just quote Henry Ford at you: "An engineer can design for ten cents
# what any damn fool can do for a Dollar".
# 
# He may have something there ...

  I prefer Heinlein's (inexact quote): "An engineer is a person who will 
  spend three hours figuring out how to do a two-hour job in one hour."

  Seems particularly appropriate to SE.

# Mike Banahan, Founder Director, The Instruction Set Ltd.


-- 
| The above opinions may not be original, but they are mine and mine alone. |
|            "While it may not be for you to complete the task,             |
|                 neither are you free to refrain from it."                 |
+-=-=-    (I wish this _was_ original!)        D. C. Sessions          -=-=-+

nmm@cl.cam.ac.uk (Nick Maclaren) (04/28/91)

>Let me just quote Henry Ford at you: "An engineer can design for ten cents
>what any damn fool can do for a Dollar".

Henry Ford had a good point, but there are other aspects of good engineering.

When I started driving, a front-wheel blowout at motorway speeds (70 mph)
was usually followed by the car somersaulting and often by the death of the
driver and all passengers.  Recently, I had one of them and the car remained
so steady that I disbelieved my senses and thought that it must be a rear
wheel.  I enquired and understand that this is due to careful design of the
steering geometry and (particularly) the wheel shape.

When you use a well-engineered product, you don't notice its design; it just
does what you want it to do.  When things go badly wrong, it fails gracefully
and avoids fatal side-effects.

How many well-engineered items of software do you know about?

Nick Maclaren
University of Cambridge Computer Laboratory
nmm@cl.cam.ac.uk

dlw@odi.com (Dan Weinreb) (04/28/91)

In article <1991Apr19.152242.8822@odgate.odesta.com> jor@odgate.odesta.com (Jor Bratko) writes:

   The above paragraph was just to illustrate a problem that can arise from
   such a definition. You end up being able to call any programming
   "software engineering". It's just a matter of whether it's
   _good_ software engineering or not. So is software engineering any different
   than programming? Does it help to have both terms mean the same thing?

Well, consider the people who designed the Yugo.  When they did this
design, were they engaged in "engineering" or not?  I'd say that even
though the Yugo was a dismal failure (see Consumer Reports), they were
engaging in "engineering".  Some of it was pretty clear poor
engineering, but it was engineering.  Similarly, what many people here
are interested in is not the promotion of "software engineering" but
the promotion of "good software engineering".  There is some
disagreement on how to judge "good", and more disagreement about means
of achieving goodness.

Is the discussion about the meaning of "software engineering" over yet?

mathew@mantis.co.uk (mathew) (04/30/91)

nmm@cl.cam.ac.uk (Nick Maclaren) writes:
> When you use a well-engineered product, you don't notice its design; it just
> does what you want it to do.  When things go badly wrong, it fails gracefully
> and avoids fatal side-effects.
> 
> How many well-engineered items of software do you know about?

Excluding the ones I wrote myself? :-)

I'm tempted to say "X Windows" to see whether the scream will carry from the
Computer Lab to here.

Ironically enough, I tried to send a response by mail. On each of the four
attempts the mail software bombed out, crashing Windows and forcing me to
re-boot the machine.

Clearly we have a long way to go.


mathew

-- 
mathew - mathew@mantis.co.uk or mcsun!ukc!ibmpcug!mantis!mathew