Software as PE
Marc Thibault
(Bruce Hayden) writes:
> So - What can you test?? I don't know.
Bruce puts his finger on it. "Software Engineer" is a
meaningless and misleading term. Don't agree? Okay, design a
test that distinguishes between a software engineer and a
programmer. Before you do that, talk to a real engineer.
The one good to come of this is now that Software Engineer is
the fashionable euphemism for Programmer, the real Systems
Analysts may be able to reclaim their title.
Best of the season,
Marc
fred j mccall 575-3539
>In article <bhayden.724605662@teal>
>(Bruce Hayden) writes:
>> So - What can you test?? I don't know.
> Bruce puts his finger on it. "Software Engineer" is a
> meaningless and misleading term. Don't agree? Okay, design a
> test that distinguishes between a software engineer and a
> programmer. Before you do that, talk to a real engineer.
Define 'real engineer' in a way that isn't recursive or
self-referential.
> The one good to come of this is now that Software Engineer is
> the fashionable euphemism for Programmer, the real Systems
> Analysts may be able to reclaim their title.
Sorry, but the difference between a 'programmer' and a 'software
engineer' is about the same as the difference between any other kind
of engineer and a good technician in the same field. A lot of 'real
engineers' who don't understand what software engineering is about
produce execrable software.
--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world." -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred....@dseg.ti.com - I don't speak for others and they don't speak for me.
Bruce Hayden
>In <88952016...@tanda.isis.org> ma...@tanda.isis.org (Marc Thibault) writes:
>A lot of 'real
>engineers' who don't understand what software engineering is about
>produce execrable software.
Here, Here
Marc Thibault
(Bruce Hayden) writes:
Maybe there, there; but around here (though not around hear),
a lot of software "engineers", who don't understand what
engineering is about, produce execrable automated systems.
Fred J has, however, asked for me to define my terms. This
deserves a well-considered response, so please stay tuned.
Cheers,
Marc
---
Marc Thibault | Automation Architect | All we are saying
ma...@tanda.isis.org | R.R.1, Oxford Mills, | is give global
CIS:71441,2226 | Ontario, Canada K0G 1S0 | warming a chance.
NC FreeNet: aa185 | |
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0
mQBNAiqxYTkAAAECALfeHYp0yC80s1ScFvJSpj5eSCAO+hihtneFrrn+vuEcSavh
AAUwpIUGyV2N8n+lFTPnnLc42Ms+c8PJUPYKVI8ABRG0I01hcmMgVGhpYmF1bHQg
PG1hcmNAdGFuZGEuaXNpcy5vcmc+
=HLnv
-----END PGP PUBLIC KEY BLOCK-----
Marc Thibault
Fred J asked me to define a real engineer. Here's my shot at
it and a monologue on the inappropriate use of this term
as applied to programmers. So that you know my bias, I have
been engineer, physicist, digital designer, programmer,
generalist-problem-solver and manager of programmers and
engineers. I am, for the time being, a designer and integrator
of systems whose primary function is the automation or
enhancement of various aspects of human interactivity. If the
term hadn't been co-opted by ageing programmers, I would
probably describe myself as a systems analyst. Sometimes, just
to be obtuse, I do. I still program for relaxation, in several
languages.
I also want to note that nothing I say here applies to those
people exploring and defining the frontiers of computation per
se. The term they misuse is "scientist".
An engineer applies time-tested methods and principles to
design artifacts integrating materials and components whose
behavior is well understood, within a specific domain of
practice. The domain distinction is important; there are
electronic engineers and mechanical engineers, but the only
oscilloscope engineers and drafting board engineers are the
ones who design oscilloscopes and drafting boards for other
engineers and technicians to use.
Not part of the definition but worth noting: When I buy
something engineered, it comes with a warranty; When I buy
software, it comes with a disclaimer.
Before everybody goes ballistic on me, this does allow for
people who could reasonably describe themselves as financial
systems engineers or control systems engineers, etc. Their use
of software as a useful component is incidental even if it's
99% of the system and they are very good at it. They just
happen to be saddled with an unreliable medium whose benefits
outweigh its risks. Calling every good programmer an engineer
is the equivalent of calling every good musician a composer.
It's great for his ego but not very accurate, and also
disappointing if you expect one to write you a theme song.
It's especially inappropriate if he's the fresh graduate of a
school that doesn't teach composition.
Software development methods are anything but time-tested;
they are changing as we speak and none has been consistently
successful at turning out software that is both reliable and
efficient. The (relatively) rare program that meets those
criteria is inevitably the result of intensive hacking by a
master craftsman whose respect for the paradigm-du-jour would
be infinitesimal if he or she cared what it was. Nor is the
behavior of the components well understood. That's why we have
bugs while engineers make design errors. We can't engineer
software because we haven't yet figured out _how_. Calling
programmers software engineers is at best wishful thinking,
and wishing only makes it so in Disneyland.
It was a software engineer who decided that the brakes on the
Fokker 100 shouldn't operate if a sensor indicated the wheels
were up. They were designated part of the "on the ground"
module. An aircraft systems engineer would have understood the
difference between the sensor and the fact, recognised that
applying brakes in midair could do no harm, and saved a few
pilots a change of underwear.
I don't think this is forever. Wide adoption of standard
objects will, in time, give the craft of programming a leg up
on the way to engineering. Engineers have used object-oriented
techniques since Leonardo, if not before; these are an
integral part of engineering practice. If that's not obvious,
get a look at an extended bill of materials (sometime known as
a "family tree") for some complex electronic or mechanical
device. I'm not sure, though, that this will happen before you
can buy software modules packaged in a processor chip with a
manufacturer's warranty. The PC BIOS industry suggests that
this is feasable and effective.
It will also require real engineering schools that teach more
than increasingly complex integer arithmetic. In addition to
dabbling in a variety of disciplines outside the one in which
they are _intensively_ trained, engineers become intimately
familiar with the common and uncommon tools and techniques of
their trade. For engineering programmers, this means learning
lots of programming languages, computer and communication
platforms, protocols, operating systems, editors, design
standards and (yes, Mabel) paradigms; and to be able to choose
well which to use for a particular solution in an end-use
context that they know very well.
No electronic engineer has ever advertised himself as expert
only with the "Apex Model 5 Logic Analyser". Anyone who
studied to be an electrical engineer with me can, in
addition to engineering electrical systems, design a logic
circuit or machine tool, program any computer, build a barn or
a cannon, distinguish between a terminal moraine and a
land-fill site, survey a meadow, and navigate a ship.
You'll know the time has come when recruitment ads for
programmers (or whatever) don't list programming languages and
operating systems, but end-use domain expertise instead. You
know there's still a long way to go when most ads for software
development _managers_ carry these lists. (You also know that
you probably don't want the job.)
John K. Scoggin, Jr.
I couldn't agree more. Once in a previous life, I made a good living at a non-existent government agency re-writing (or re-inventing) software because the stuff the engineers/physicists wrote wouldn't fit in a computer we could fit into a satellite (well, maybe if we used a Saturn 5 it might fit) :-)
On the topic of academic credentials, I would say that some companies are starting to see the light. I have no degree, but I've taught part-time at two colleges/universities at the undergraduate and graduate level. They weren't that hung up on the paper. Neither is my current employer.
- John
---
+---------------------------------------------------------------------+
| John K. Scoggin, Jr. Email: sco...@delmarva.com |
| Supervisor, Network Operations Phone: (302) 451-5200 |
| Delmarva Power & Light Company Fax: (302) 451-5321 |
| 500 N. Wakefield Drive NOC: (800) 388-7076 |
| Newark, DE 19714-6066 |
+---------------------------------------------------------------------+
John De Armond
> Fred J asked me to define a real engineer. Here's my shot at
Very excellent analysis. Couple of additional thoughts.
> Software development methods are anything but time-tested;
> they are changing as we speak and none has been consistently
> successful at turning out software that is both reliable and
> efficient. The (relatively) rare program that meets those
> criteria is inevitably the result of intensive hacking by a
> master craftsman whose respect for the paradigm-du-jour would
> be infinitesimal if he or she cared what it was. Nor is the
> behavior of the components well understood. That's why we have
> bugs while engineers make design errors. We can't engineer
> software because we haven't yet figured out _how_. Calling
> programmers software engineers is at best wishful thinking,
> and wishing only makes it so in Disneyland.
I don't believe software creation will ever become an engineering
discipline any more than the creation of oil paintings will.
Both are inextricably linked to the craftsman's artistic intellect.
I'm one of those people who is educated in a conventional engineering
discipline and got into software after about 15 years of conventional
practice. I was able to watch the evolution of my brand of engineering
(nuclear instrumentation) move from the sliderule era through the
calculator and into the computer age. At the same time I am a (budding)
artist, working with hot glass. I can therefore observe both sides.
Consider a few things. First, languages. It is intrinsicly difficult to
move between programming languages. Some people are gifted in this
area, of course, but for most people, learning a new programming language
is quite a chore. That is because each language embodies a different
way of approaching the creative process. Assembler programmers tend
to do things quite differently than SQL programmers. This is at odds with
the conventional engineering disciplines where the same methodologies
are used throughout. I found little difficulty, for example, on
picking up on designing hydraulic systems. A little bit of reading
and some study to find out what the standards were and away I went.
Consider artistic media, on the other hand. An oil painting artist does
NOT easily move into, say, stained glass. A wood carver cannot easily
become a painter. This is quite in parallel with programming. While
a central artistic ability has to be present in both cases, one's skill set
may only match certain media. I personally have tried for years to find
a media in which to express some of my artistic ideas. Hot glass appears
to be it. I tried drawing and cartooning and painting and sucked bilgewater
at them all. Woodcrafts are not much better. Yet I find working with
glass easy and people tell me my work is quite good.
Same with software. As a development manager, I've found most programmers
excel in one or two areas. I have little patience with end-users and
therefore do poorly with applications. Communications, on the other hand,
seemed a natural.
> I don't think this is forever. Wide adoption of standard
> objects will, in time, give the craft of programming a leg up
> on the way to engineering.
I don't much think so. I suspect it will further the development of a
technician/craftsman class of programmers analogous to the carpenter
or electrician. These people will bolt together variations of standardized
applications just as carpenters hammer togethers pretty standard structures
from "objects" of wood (the plank.) In this niche may be the place for
the licensed engineer to oversee the design of these things when the end
result has public safety implications.
This brings up another difference between engineers and software development.
Most any engineered system can be proved correct or else the weaknesses
can be comprehensively identified. Provably correct designs have
been a big thing in the nuclear biz for the last 20 years or so. It is
this concept that has kept computers out of the reactor control and
protection loop until recently and even then, the impossibility of provably
correct software systems is addressed by massively redundant systems AND
by keeping the human operator in the loop.
> No electronic engineer has ever advertised himself as expert
> only with the "Apex Model 5 Logic Analyser". Anyone who
> studied to be an electrical engineer with me can, in
> addition to engineering electrical systems, design a logic
> circuit or machine tool, program any computer, build a barn or
> a cannon, distinguish between a terminal moraine and a
> land-fill site, survey a meadow, and navigate a ship.
Yup, and that is in stark contrast with many "CS" programs that
seldom venture out to anything outside the computer.
I think the titles "science" and "engineering" get tagged onto what
programmers because a) academians realize the engineering schools get
all the money and thus want the same legitimacy as, say, the school
of nuclear engineering, b) because corporate managers realize the same
thing applies in business and c) upper management could not stand the
idea of paying big bucks to a bunch of people who are identified as
artists.
John
--
John De Armond, WD4OQC |Interested in high performance mobility?
Performance Engineering Magazine(TM) | Interested in high tech and computers?
Marietta, Ga | Send ur snail-mail address to
j...@dixie.com | per...@dixie.com for a free sample mag
Need Usenet public Access in Atlanta? Write Me for info on Dixie.com.
Charles Kincy
>ma...@tanda.isis.org (Marc Thibault) writes:
[Programmers are more like artists, rather than engineers]
Hey, I think I like that! :-)
"What do you do for a living?"
"Oh, I'm a computer craftsman. :-)"
>This brings up another difference between engineers and software development.
>Most any engineered system can be proved correct or else the weaknesses
>can be comprehensively identified. Provably correct designs have
>been a big thing in the nuclear biz for the last 20 years or so. It is
>this concept that has kept computers out of the reactor control and
>protection loop until recently and even then, the impossibility of provably
>correct software systems is addressed by massively redundant systems AND
>by keeping the human operator in the loop.
It's possible to prove algorithms correct, also. But it's usually
a lot more hazardous to one's mental health. Once in a great blue moon,
a software system is proven correct. But that's pretty rare.
You'll never see a correctness proof for Unix, for example. Hee. :-)
>> No electronic engineer has ever advertised himself as expert
>> only with the "Apex Model 5 Logic Analyser". Anyone who
>> studied to be an electrical engineer with me can, in
>> addition to engineering electrical systems, design a logic
>> circuit or machine tool, program any computer, build a barn or
^^^^^^^^^^^^^^^^^^^^[shyeeeaah!]
>> a cannon, distinguish between a terminal moraine and a
>> land-fill site, survey a meadow, and navigate a ship.
[Well, goody for him. :-) Actually, as a CS student, I can do
5 of the things he lists above. I guess my education wasn't thoroughly
useless (see below)].
>Yup, and that is in stark contrast with many "CS" programs that
>seldom venture out to anything outside the computer.
Many, but not all.
See, my CS degree program is pretty well-rounded. Only about 40 of
the 130 hours are in computer science. The others are in calculus
[3 semesters, but no diff eq...we have to know how to do them anyway,
though, because of other classes], physics [both electrical and mechanical]
either biology or chemistry [student's choice], some lit. and hist., 12
hours of courses from another science or engineering degree program, and
two classes in electrical engineering [it used to be Circuits I and
Logic Analysis, but then they changed the Circuits requirement into
Digital Systems Design, which is a lot more useful to a CS student anyway,
so I've found. Although, I'm kinda glad I took the circuits class,
even though I didn't do so well in it], as well as a few other things we get
to choose for ourselves. Furthermore, we have to know Fortran for
two courses, but we aren't allowed to take the Fortran course for
credit. Our department figures a 1/2-competent CS student can learn
it by themselves. (Engineers, on the other hand, are required to
take the Fortran course. Hmmm.... :)
Most of the engineering curricula around here are pretty non-customizable.
UMR Engineering graduates are not particularly well-rounded. But, that doesn't
seem to inhibit their getting good-paying jobs. :-) Actually,
engineering students would have a much better time if colleges would
finally admit that it takes longer than 4 years to get a good
college education these days. There's just too much to learn in 4
years. 4 1/2 or 5 would be more manageable.
Anyway, I discovered that a CS degree should not train you as much in
CS, but it should train you in research and self-education methods,
because the stuff you learns as a freshman is obsolete by graduation.
One must admit that this doesn't happen to engineers quite as much.
>I think the titles "science" and "engineering" get tagged onto what
>programmers because a) academians realize the engineering schools get
>all the money and thus want the same legitimacy as, say, the school
>of nuclear engineering, b) because corporate managers realize the same
>thing applies in business and c) upper management could not stand the
>idea of paying big bucks to a bunch of people who are identified as
>artists.
[a] Not true. We know our place. But, a CS degree here is more
challenging then, say, a degree in psychology, and probably as challen-
ging as a degree in chemistry. So, I think we deserve *some* legitimacy.
We pay our dues in calc, chem, and physics just like the engineers do.
Not that we especially need all of it in our careers. It's sort of like
a rite of passage. :)
[b] Maybe. I'd like to see an electrical engineer design an operating
system. That person could probably do it, but they wouldn't like it.
CS people *like* doing that sort of stuff. Does that mean we should
pay them less money? (Anyway, why did the EE go through the pain and
suffering of a EE degree if he/she just wanted to write operating
systems? :-)
[c] Hee. You're probably right. :-)
cpk
--
"The WHITE ZONE is for loading and unloading only. If you gotta load or un-
load, go to the WHITE ZONE. You'll love it. It's a way of life!" --Zappa
Technology always seems to keep one step ahead of human wisdom.
Pete Hardie
> Not part of the definition but worth noting: When I buy
> something engineered, it comes with a warranty; When I buy
> software, it comes with a disclaimer.
A comment: Most warranties I read attempt to disclaim all faults except
material failure. They do not state that the product will perform in the
desired manner, they guarantee a replacement if it fails to perform.
> It was a software engineer who decided that the brakes on the
> Fokker 100 shouldn't operate if a sensor indicated the wheels
> were up. They were designated part of the "on the ground"
> module. An aircraft systems engineer would have understood the
> difference between the sensor and the fact, recognised that
> applying brakes in midair could do no harm, and saved a few
> pilots a change of underwear.
First of all, is this a confirmed thing?
Secondly, just to clarify: is the problem here that a sensor failed, thus
preventing the brakes from operating when the wheels were in fact down?
Thirdly, you are making a general statement about software people based on
a single decision by one. Another software engineer might have seen that
applying the brakes with the gear up was non-harmful and allowed it. Certainly
the review of the functionality should have pointed this out. This is not
a condemnation of software engineers, but rather of narrow-mindedness in design,
not too far removed from the Ford Pinto fuel tank fiasco.
> No electronic engineer has ever advertised himself as expert
> only with the "Apex Model 5 Logic Analyser". Anyone who
> studied to be an electrical engineer with me can, in
> addition to engineering electrical systems, design a logic
> circuit or machine tool, program any computer, build a barn or
> a cannon, distinguish between a terminal moraine and a
> land-fill site, survey a meadow, and navigate a ship.
Similarly, any 'Computer Science Engineer' who studied with me can build a
logic circuit, program a computer, plot ballistic trajectories, design a
bridge or scaffold-tower, budget a hydro-electric project, write a magazine
article, balance a ohydation-reduction reaction, or anneal a metal blade.
Breadth in education is not prohibited to a CS major, y'know, nor is it a
discouraged thing.
I'll agree that software development is certainly a long way from the
disciplines of civil and mechanical engineering, or even the newcomer of
electrical engineering. And perhaps it is a bit premature for us to be using
'engineering' as a descriptive term. But we *are* getting there, and we
*are* using the best methods to make software into a reliable feature.
> You'll know the time has come when recruitment ads for
> programmers (or whatever) don't list programming languages and
> operating systems, but end-use domain expertise instead. You
> know there's still a long way to go when most ads for software
> development _managers_ carry these lists. (You also know that
> you probably don't want the job.)
Interestingly, I have yet to enter a job with more than a minimal end-use
domain knowledge of the product, yet none of the jobs' I've had have ever
failed because of a lack of that knowledge. I get the info from those with
the domain expertise, and apply *my* expertise to program it best. I've seen
some truly horrid software produced by people with excellent end-use domain
knowledge, but little software knowledge - and it shows.
--
Pete Hardie: phardie@nastar (voice) (404) 497-0101
Digital Transmission Systems, Inc., Duluth GA
Member, DTS Dart Team | cat * | egrep -v "signature virus|infection"
Position: Goalie |
Hans Lachman
>
> "Software Engineer" is a meaningless and misleading term.
In my opinion, a "software engineer", in addition to being a competent
programmer, should also have the following characteristics:
- understands and applies general engineering principles
- has at least a passing knowledge of other engineering and/or
physical science fields, helping him/her communicate with
technical professionals of other backgrounds
- knows how use a library to research a technical topic
- understands the fundamentals of computer hardware design and
operating systems
- knows well-known programming techniques not specific to one
language (like stuff from Knuth's books)
- can do "systems analysis" (product requirements analysis, functional
analysis)
- can write good functional specification and design specification
documents
- is familiar with commonly-accepted software modeling methods
(e.g., data flow diagrams)
- knows enough about the state of the art to identify, most of the
time, when a proposed solution is a reinvention of the wheel
- has a level of judgement that results in good cost/benefit trade-offs
- can write implementation notes that help future maintainers of
his/her code
- can create effective test plans
- can communicate effectively, regarding his/her software, with other
departments (e.g., other development teams, software test, software
integration, marketing, product documentation, customer support)
Anyone who demonstrates the above characteristics qualifies as a software
engineer, in my book. (Sorry, no black-and-white, 1-or-0 tests.)
In article <52232245...@tanda.isis.org> ma...@tanda.isis.org writes:
>
> No electronic engineer has ever advertised himself as expert
> only with the "Apex Model 5 Logic Analyser".
Software engineers advertise themselves this way because the hiring
managers typically hire this way. I would like to see the day when
hiring managers put more weight on how good an engineer the candidate
is, based on criteria like those in my list above, and put secondary
weight on whether the candidate knows how to tweak bit X in operating
system Y.
Hans Lachman
lac...@netcom.com
Mark A Biggar
>In article <52232245...@tanda.isis.org> ma...@tanda.isis.org writes:
>> It was a software engineer who decided that the brakes on the
>> Fokker 100 shouldn't operate if a sensor indicated the wheels
>> were up. They were designated part of the "on the ground"
>> module. An aircraft systems engineer would have understood the
>> difference between the sensor and the fact, recognised that
>> applying brakes in midair could do no harm, and saved a few
>> pilots a change of underwear.
>First of all, is this a confirmed thing?
>Secondly, just to clarify: is the problem here that a sensor failed, thus
>preventing the brakes from operating when the wheels were in fact down?
It is my understanding that the decision of the software engineer was the
CORRECT one. On a large jet aricraft the wheel brakes MUST NOT be applied
until after the wheels are on the ground and rolling because there is too
much chance of blow-out on touchdown otherwise. The real problem was that
there was no emeregecy override in case the weight-on-wheels sensor failed.
--
Mark Biggar
m...@wdl1.wdl.loral.com
Cameron Laird
.
.
.
>In article <52232245...@tanda.isis.org> ma...@tanda.isis.org writes:
>>
>> No electronic engineer has ever advertised himself as expert
>> only with the "Apex Model 5 Logic Analyser".
>
>Software engineers advertise themselves this way because the hiring
>managers typically hire this way. I would like to see the day when
>hiring managers put more weight on how good an engineer the candidate
>is, based on criteria like those in my list above, and put secondary
>weight on whether the candidate knows how to tweak bit X in operating
>system Y.
see it, but is history on our side? This is a big topic,
but are either of these aspects clear to others:
1. is there something inherent in software
work that makes the contractor/high
turnover/narrow specialization/inade-
quate training/... constellation more
probable/profitable/desirable than
obtains in other engineering domains?
2. has the answer to 1. changed in the
last ten years? How will it change in
the next ten?
.
.
.
--
Cameron Laird
cla...@Neosoft.com (claird%Neoso...@uunet.uu.net) +1 713 267 7966
cla...@litwin.com (claird%litwi...@uunet.uu.net) +1 713 996 8546
James Hanlon
...excellent sketch of an engineering professional deleted..
: In article <52232245...@tanda.isis.org> ma...@tanda.isis.org writes:
: >
: > No electronic engineer has ever advertised himself as expert
: > only with the "Apex Model 5 Logic Analyser".
:
: Software engineers advertise themselves this way because the hiring
: managers typically hire this way. I would like to see the day when
: hiring managers put more weight on how good an engineer the candidate
: is ...
:
: Hans Lachman
: lac...@netcom.com
Management apparently believe that the "hire the exact language match"
technique works, or it would not persist as long as it has. Software
professionals play the game cynically, flooding entire resume pages with
acronyms and buzzwords, hoping for a hit. It's a meaningless, destructive,
dynamic; breaking it is in practice extremely difficult (I know; I've tried).
As to what is perpetuating this situation, I think that management theory
is predicated on the successful metrication of manufacturing and distribution
firms, largely in the automobile industry, in the mid-twentieth century.
Hence the glorification of Taylor, Shewhart, and Deming, et al.. Their
ideas of work flow, inventory management, statistical quality control--so
valid when marrying crankshafts to engine blocks--are simply not appropriate
to abstractions realized in discrete systems. No one in management realizes,
or admits, this, and so we see "metrics" like LOC taken seriously--even worse,
we see time derivatives, extrapolations, even statistical variance, used to
justify decisions regarding substantial portions of a business's resources.
The spectacle of highly-paid managers looking at graphs of square roots
of LOC counts is appalling enough, but when it affects my livelihood, I
cringe. I mean, chi-square! Of conditional logic! Somebody give those guys
a cylinder head.
So, I think management is simply wrongheaded, and is doomed to fail until
an appropriate system model is substituted for the current manufacturing one.
Otherwise, "I have produced 2000 lines of C code for the SPARC" will continue
to be an attractive attribute of a potential hire.
Jim Hanlon
tcu...@ddsw1.mcs.com
Hans Lachman
I forgot one important point (and possibly others):
- can handle or at least help with administrative tasks, such as
project planning (estimating schedules, estimating manpower and
equipment requirements), managing a bug-tracking database, and
doing engineering-related paperwork (like patent applications)
Hans Lachman
lac...@netcom.com
Grover McCoury
I pulled the following definition from a recent posting to the net:
-------------------------------cut here--------------------------------
From the "Encyclopedia of Occupational Titles":
(Capitalized words within text were in italics)
Professional, Technical, and Managerial Occupations
03 Computer-related occupations
030 Occupations in systems analysis and programming
030.062-010 SOFTWARE ENGINEER (profess. & kin.)
Researches, designs, and develops computer software systems, in conjunction
with hardware product development, for medical, industrial, military, commu-
nications, aerospace, and scientific applications, applying principles and
techniques of computer science, engineering, and mathematical analysis:
Analyzes software requirements to determine feasibility of design within time
and cost constraints. Consults with hardware engineers and other engineering
staff to evaluate interface between hardware and software, and operational
and performance requirements of overall system. Formulates and designs software
system, using scientific analysis and MATHEMATICAL MODELS to predict and
measure outcome and consequences of design. Develops and directs software
system testing procedures, programming, and documentation. Consults with
customer concerning maintenance of software system. May coordinate installation
of software system.
Yet another $.02 worth from...
/**********************************************************************
Grover McCoury
@ Fujitsu Network Switching Of America, Inc.
4403 Bland Road
Raleigh, NC 27609
audio: 919-790-3111
electronic: gcm%fns-nc1.fns.com@fai
***********************************************************************/
James Hanlon
:
: I forgot one important point (and possibly others):
:
: - can handle or at least help with administrative tasks, such as
: project planning (estimating schedules, estimating manpower and
: equipment requirements), managing a bug-tracking database, and
: doing engineering-related paperwork (like patent applications)
With these sorts of talented engineers on the job, who needs managers?
Or do they realize that?
: Hans Lachman
: lac...@netcom.com
James E. Hanlon, PE
tcu...@ddsw1.mcs.com
Mike Mattix
> lac...@netcom.com (Hans Lachman) writes:
> :
> : I forgot one important point (and possibly others):
> :
> : - can handle or at least help with administrative tasks, such as
> : project planning (estimating schedules, estimating manpower and
> : equipment requirements), managing a bug-tracking database, and
> : doing engineering-related paperwork (like patent applications)
> :
> With these sorts of talented engineers on the job, who needs managers?
> Or do they realize that?
>
>
1. Induce/create inefficiencies
2. Throttle creativity
3. Create political environment
etc.
--
Mike Mattix
Agricultural Group of Monsanto
P.O. Box 174
Luling, LA 70070
INTERNET Address: dmm...@bigez.monsanto.com
Hans Lachman
>lac...@netcom.com (Hans Lachman) writes:
>:
>: I forgot one important point (and possibly others):
>:
>: - can handle or at least help with administrative tasks, such as
>: project planning (estimating schedules, estimating manpower and
>: equipment requirements), managing a bug-tracking database, and
>: doing engineering-related paperwork (like patent applications)
>:
>With these sorts of talented engineers on the job, who needs managers?
>Or do they realize that?
>
Are you sure you work in the real world? It's not unusual for managers
to ask their engineers for their opinions on how long a project will
take and how much manpower will be needed. The assumption is that
the engineer can provide meaningful input (depending on his/her level
of seniority).
Is this not the case in other engineering fields?
Hans Lachman
lac...@netcom.com
John De Armond
>1. is there something inherent in software
> work that makes the contractor/high
> turnover/narrow specialization/inade-
> quate training/... constellation more
> probable/profitable/desirable than
> obtains in other engineering domains?
Yes. I'll be addressing the business environment only. Academics/research
is not addressed.
There are several things. One is the invasion of business by the MBAs
and the chaos that has resulted. National Columnist Mike Royko wrote
an article on this last week that addresses the issue better than I
could. The bottom line is the corporate environment in the typically
non-high-technology company is intolerable to the creative types who
are good programmers. Dress codes, the demand for abject comformity,
office politics, the technological illiterates, salesmen, all these
are the anathema of the creative programmer. Over the last 5 to 10
years I've observed the mechanism work to distill the corporate computing
staff down to those who are incompentent and simply want to draw a paycheck
and those who are temporarily stuck in some place they don't want to be.
As a contractor, I know that my stay in a given company is short, I know
I don't have to become immersed in the corporate culture and the money
I charge makes up for my having to be in the corporate office. Plus
I can do things as a contractor, such as work out of my office, that
direct employees (mushrooms) cannot do.
I don't see this confined to just software. Back when the hot chip of
the day was the new Z80, I worked for M&M Mars as a staff engineer.
I was a duck out of water and lasted barely 2 years. Mars more or less
explicitly admitted that contractors were the way to go by farming out
almost all design and engineering to contractors. Staff engineers
were supposed to do nothing more than administer the contracts and
consult to maintenance.
Another consideration is that the truly creative people who make the
best programmers get bored and are seldom challenged enough to keep
their attention. Contractors, on the other hand, can change jobs
as often as they desire.
Finally there is the ever-increasing interference of government in
employer-employee relations. Anti-discrimination laws, OSHA, Americans
with Disabilities Act, the coming mandatory leave law, unemployment and
workman's comp and all the other bullshit the government dishes out
supposedly to benefit employees is making it increasingly more
attractive to use contractors. As an employer, I will do everything I
can to keep my staff size below the trigger points of the various laws.
Contractors let me do that. The contractor also benefits because part of
the money I'd have to spend on mandated employee "benefits" can be paid
as compensation.
>2. has the answer to 1. changed in the
> last ten years? How will it change in
> the next ten?
Oh absolutely. Downsizing and the continuing movement of job opportunities
from the corporate monoliths to small enterpreneuring enterprises means
fewer and fewer businesses can afford to keep the deadwood on staff.
Small companies just flat don't have enough work to keep a staff of
engineers or programmers busy full time.
What we're seeing is proof that several hundred thousand smart businessmen
can always outsmart a few hundred congresslime and bureaucrats. We'll
figure out how to make money regardless of what Congress tries to do
to us.
Michael E
In article <C0Hu8...@ddsw1.mcs.com> tcu...@ddsw1.mcs.com (James Hanlon) writes:
>lac...@netcom.com (Hans Lachman) writes:
:
< stuff concerning the definition of a software engineer >
:
>With these sorts of talented engineers on the job, who needs managers?
The sales department- they're next on the list.
>Or do they realize that?
No- that's why they're managers.
"Well, there goes this year's pay raise. All $20 of it."
fred j mccall 575-3539
>I pulled the following definition from a recent posting to the net:
>-------------------------------cut here--------------------------------
>From the "Encyclopedia of Occupational Titles":
>(Capitalized words within text were in italics)
>Professional, Technical, and Managerial Occupations
>03 Computer-related occupations
>030 Occupations in systems analysis and programming
>030.062-010 SOFTWARE ENGINEER (profess. & kin.)
>Researches, designs, and develops computer software systems, in conjunction
>with hardware product development, for medical, industrial, military, commu-
>nications, aerospace, and scientific applications, applying principles and
>techniques of computer science, engineering, and mathematical analysis:
>Analyzes software requirements to determine feasibility of design within time
>and cost constraints. Consults with hardware engineers and other engineering
>staff to evaluate interface between hardware and software, and operational
>and performance requirements of overall system. Formulates and designs software
>system, using scientific analysis and MATHEMATICAL MODELS to predict and
>measure outcome and consequences of design. Develops and directs software
>system testing procedures, programming, and documentation. Consults with
>customer concerning maintenance of software system. May coordinate installation
>of software system.
Gee, that sounds like my job description. I wonder if someone should
send this to the Texas State Legislature?