Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What's different about software?

3 views
Skip to first unread message

Dave Berry

unread,
Nov 21, 1994, 10:12:14 AM11/21/94
to
An acquaintance of mine is one organiser of a successful M.Sc. course
on Engineering Project Management. I was chatting to him recently, and
the question arose of what is different about software engineering
management. He says that most of his course is not about the technical
details of engineering, but about management, and that much of this
is applicable to any field of engineering management. Last year they
had their first software project, and the fact that it was software
didn't cause any problems.

I don't know much about management, so I wasn't very informative.
Most software engineering texts compare their ideas of good management
with the typically poorly managed projects of the software world,
rather than management in other engineering disciplines. What do people
think is different (if anything) about managing a software project?

Dave.
--
One more touch and then you'll see Harlequin Ltd.,
Worlds of hidden mystery, Barrington Hall,
Visions of beyond recall. Barrington,
(You know you're only dreaming). Cambridge, UK.

D. C. Sessions

unread,
Nov 21, 1994, 2:48:50 PM11/21/94
to
In article <CzMI8...@harlequin.co.uk> da...@harlqn.co.uk (Dave Berry) writes:

>I don't know much about management, so I wasn't very informative.
>Most software engineering texts compare their ideas of good management
>with the typically poorly managed projects of the software world,
>rather than management in other engineering disciplines. What do people
>think is different (if anything) about managing a software project?

The biggest difference is that the SE people KNOW that their management needs
improvement, and have set out with a relatively clean slate to improve it.
The lack of historical continuity which started out as being such a crippling
liability in the past has now become a sort of back-handed advantage.

Overall, though, I've found that SE is remarkably general. You can apply SE
principles to hardware design so readily that it's downright scary. It'll be
really funny when the roles get reversed....

Paul C. George

unread,
Nov 21, 1994, 5:21:07 PM11/21/94
to
In article <CzMI8...@harlequin.co.uk> Dave Berry,

da...@harlqn.co.uk writes:
> What do people think is different (if anything) about managing a
software project?

For the most part projects is projects. The main difference between
software projects and others is experience. Software has less of a
track record (less prior art, fewer conventions) than other forms of
engineering, and many managers _assume_ that it is something
special. It is no coincidence that the Key Process Areas of the
CMM's first two levels address little that is software specific.
{For that matter software engineers seem to think they are something
special - "Managing a team of first rate programmers is a task
roughly equivalent to herding cats"}

In my experience there is no significant difference from a
management standpoint between software engineering and (for example)
electronic engineering in the early activities leading to detailed
design . There are analagous tasks which differ only in the specific
engineering techniques and notations. The important thing to
remember is that source code corresponds to an Engineering Drawing
rather than a piece of hardware. Similarly, most analysis or design
representations correspond to schematics. The key to success is
"Drawing Checks" - inspections.

Software does suffer from the fact that there are no standard
engineering notations and conventions. This does lead to
communications problems, particularly in the areas of specification
and interpretation. Objective quality and qualification criteria can
be scarce, and comparing things can be difficult. A partial solution
is more careful reviews/inspections focusing on identifying
ambiguities.

There are a few differences when a project reaches the stage of
integration and qualification. Managing software builds and managing
configurations can be a bit more involved. Assessing the impact of
anomalies and planning rework can be a significant effort. Since it
is very difficult to a priori estimate the amount of rework, the
number of test builds/cycles can be indeterminate making delivery
and resource planning difficult.

==================================================================
===
There are two kinds of a fool:
One says !This is old and therefor good'
The other says !This is new and therefor better!
_____________________________________________________________________
Paul C. George Email: pge...@bailey.com
Sr. Methods Specialist Phone: (216)585-8675
Elsag Bailey Process Automation,
Cleveland, Ohio, USA
_____________________________________________________________________
Disclaimer: I am neither a ventriloquist nor a dummy
=====================================================================

Tony Karp

unread,
Nov 21, 1994, 5:39:33 PM11/21/94
to
da...@harlqn.co.uk (Dave Berry) wrote:

>What do people think is different (if anything) about
>managing a software project?


A software project is joint development of intellectual
property. Other engineers work on tangible things. Like bridges
and airplanes.

Image, if you will, that your software project is producing,
instead of an accounting system, a novel or an opera. That is
closer to the sort of thing you're really building.

Now, how would you manage a group of people working together to
write an opera?

peace...

Tony Karp, TLC Systems Corp, NYC -- tk...@pipeline.com

Patrick D. Logan

unread,
Nov 22, 1994, 10:33:03 AM11/22/94
to
In article <JON.94No...@bilbo.radonc.washington.edu> j...@bilbo.radonc.washington.edu (Jon Jacky) writes:

>The engineers usually [produce] primarily documents...
>So maybe it's not so different after all.

Dikstra (sp? apologies) made this analogy many years ago:

(Paraphrasing)

The electronics designers essentially take the same design and apply different
technolgies to it over and over.

The software designers essentially take the same technology and apply it to
different designs over and over.

(End)

Now that is an oversimplification, but a very useful one to begin to
understand the fundamental differences between software development and other
engineering disciplines.

I have not decided whether this characterization of software development has
as much to do with the poor state of software development as does the presence
of very limited talent among software developers. Frankly, most of us are just
not very good.


Patrick...@ccm.jf.intel.com
Intel ProShare Teleconferencing
(503) 264-9309 FAX: (503) 263-3375

"What I envision may be impossible, but it isn't impractical."
-Wendell Berry

Jon Jacky

unread,
Nov 22, 1994, 4:37:19 AM11/22/94
to
In article <3ar7j5$e...@pipe1.pipeline.com> tk...@pipeline.com (Tony Karp) writes:

> A software project is joint development of intellectual
> property. Other engineers work on tangible things. Like bridges
> and airplanes.

Actually it is usually *not* the engineers out there bending metal,
setting rivets, and pouring concrete. The engineers usually work in an
office, and what comes out of the office are primarily documents,
(often in the form of drawings) that instruct how other people are to
bend metal etc. So maybe it's not so different after all.

- Jon
--

Jonathan Jacky j...@radonc.washington.edu
Radiation Oncology RC-08 voice: (206)-548-4117
University of Washington FAX: (206)-548-6218
Seattle, Washington 98195
USA

Terry Bollinger

unread,
Nov 22, 1994, 7:33:40 PM11/22/94
to

Hi folks,

In article <CzMI8...@harlequin.co.uk>, Dave Berry <da...@harlqn.co.uk>
raises an interesting question:

> ... What do people think is different (if anything) about managing a
> software project [versus managing a hardware engineering project]?


Well, there is this: Given _exactly_ the same degree of management controls
over the design and implementation process, the software guy can get away
with product-change murder in about the same time frame that a traditional
hardware type can blink once or twice.

Furthermore, the software type can replicate parts of a bad design with
similar blinding speed, so what might have been _one_ design problem in
hardware can become a dozen or so separate ones in the software version.


To me this argues that to be truly effective, software management either
needs to:

a) Brute-force the issue by making the software every bit as hard to
change as hardware is, or

b) Get the management process to work on the same eye-blink time scale on
which software is capable of being changed.


Alas, I strongly suspect that in reality the most popular way to deal with
this time-scale problem is for the software types simply to let their bosses
(who are often from hardware backgrounds) _think_ that the slow-speed, large-
granularity controls of hardware management are just fine for software, too.
They then use the resulting "reality gap" to go on and get the job done the
way they wanted too in the first place, regardless of what the schedule said.

If it works, everyone is happy (if deluded!), and they use the resulting set
of great process stats to apply for SEI Level 3 (or 4?) status. If it falls
flat on its face, the boss does an intensive search for references on the
software crisis and why software is SO hard to estimate... :)

Cheers,
Terry Bollinger

Tony Karp

unread,
Nov 24, 1994, 5:01:04 PM11/24/94
to
Here's another thing that's different about software.

It can only be fixed by the manufacturer. This is truer for
software than for most other products.

If your TV or VCR or car breaks, you can probably get it fixed
locally.

Not so with software. If MS Word is broken only Microsoft can
fix it.

Can anyone point out the implications of this?

Also:

Software doesn't wear out -- it becomes obsolete.

Ian Mitchell

unread,
Nov 25, 1994, 10:54:19 AM11/25/94
to

>In article <3ar7j5$e...@pipe1.pipeline.com> tk...@pipeline.com (Tony Karp) writes:
>> A software project is joint development of intellectual
>> property. Other engineers work on tangible things. Like bridges
>> and airplanes.

>Actually it is usually *not* the engineers out there bending metal,
>setting rivets, and pouring concrete. The engineers usually work in an
>office, and what comes out of the office are primarily documents,
>(often in the form of drawings) that instruct how other people are to
>bend metal etc. So maybe it's not so different after all.
>- Jon

It used to be very different, but is becoming less so. The reason lies
in the software tool crisis, which has not kept up with increasing
software complexity.

Traditional engineers like bridge-builders have had adequate tools
for the job for years (like rivet guns and cranes), and this makes the
projects easier to manage and realise. Managers know that the
engineers aren't going to mould rivets between their teeth and
hammer them in by hand, they are going to use proper tools for
the job. The capabilities of these tools are well understood,
which makes it easier to plan ahead.

The problem is, of course, that *software* engineers have had no
equivalent tools for projects of equal (or greater) complexity. This
makes it very difficult to manage an SE project because there is a
lot of grunt work that gets in the way with plenty of room for error.
We're cracking our teeth and breaking our fingers every day with
rivets hand-coded in C++. The situation is now changing as more
CASE tools become available, but we are still only part way there.


Regards, Ian Mitchell

-----------------------------------------------------
Ian Mitchell Ian.Mi...@sunderland.ac.uk
-----------------------------------------------------
sic biscuitus disintegrat
-----------------------------------------------------

Guy A. Lyle

unread,
Nov 25, 1994, 8:09:05 PM11/25/94
to
Patrick D. Logan, patrick...@ccm.jf.intel.com writes:
>I have not decided whether this characterization of software development
has
>as much to do with the poor state of software development as does the
presence
>of very limited talent among software developers. Frankly, most of us
are just
>not very good.

Please consider the relative youthfulness of the software engineering
"profession" compared to that of electrical or mechanical engineering.
We are "not very good" because our branch of engineering has yet to
establish reliable, repeatable processes. Many of us got into the ball
game with degrees in things other than software engineering (such degrees
didn't exist to begin with!).

Guy Lyle
************************************************
*** Guy A. Lyle (gl...@interaccess.com) ***
************************************************

Bruce Karsh

unread,
Nov 26, 1994, 5:43:56 AM11/26/94
to
In article <3b61ri$1...@nntp.interaccess.com> Guy A. Lyle <gl...@interaccess.com> writes:

>Please consider the relative youthfulness of the software engineering
>"profession" compared to that of electrical or mechanical engineering.
>We are "not very good" because our branch of engineering has yet to
>establish reliable, repeatable processes. Many of us got into the ball
>game with degrees in things other than software engineering (such degrees
>didn't exist to begin with!).

I'm getting tired of all the negativity about software.

There are a lot of software-based products on the market. For the most
part, they perform quite well, and customers love them and buy them at a
rate that's really amazing.

Meanwhile I can't turn on my TV without hearing about the failures of the
hardware engineers. The Pentium chips CPU doesn't divide correctly,
Ford pickup trucks explode on impact, Chrysler Minivans doors don't
latch safely, airplanes keep crashing.

There's plenty of problems with hardware engineering. In comparison,
software engineering is not doing a bad job. Software engineers regularly
crank out very good products at a very reasonable development cost. I look
forward to a time when software engineers can do an even better job than
they do now.

But all this hardware-engineering envy is really misplaced. Software
engineers are making great products and the hardware engineering
profession has a lot to learn from us.

Larry Dick

unread,
Nov 27, 1994, 5:09:47 PM11/27/94
to
In <CzMI8...@harlequin.co.uk> da...@harlqn.co.uk (Dave Berry) writes:

>

It seems to me that when multiple disciplines interact with software,
then decisions are made (sometimes on the fly) that force software to
pick up the pieces for hardware problems. Even at system design, trade
offs are made that add to the detail and complexity of software.

When was the last time a hardware designer offered to add a few IC's to
the board to mitigate a software problem unless the software was shown
to be unable to perform without added hardware?

Yet, this is how it should be, software is the easiest environment to
make a change in. It is usually easier to modify software than hardware
(mechanical or electrical). It is usually easier to develop control
logic in software than in hardware, etc. And finally, it is usually
easier to ship software than hardware.

But, the cost of all of this is that the software becomes more and more
complex while at the same time the hardware environment is stripped of
all the complexity that can be reasonably disposed of.


David W. Griffin

unread,
Nov 28, 1994, 7:25:19 AM11/28/94
to
In article f...@ixnews1.ix.netcom.com, Lar...@ix.netcom.com (Larry Dick) writes:
[snip]

> When was the last time a hardware designer offered to add a few IC's to
> the board to mitigate a software problem unless the software was shown
> to be unable to perform without added hardware?
>
> Yet, this is how it should be, software is the easiest environment to
> make a change in. It is usually easier to modify software than hardware
> (mechanical or electrical). It is usually easier to develop control
> logic in software than in hardware, etc. And finally, it is usually
> easier to ship software than hardware.
>
> But, the cost of all of this is that the software becomes more and more
> complex while at the same time the hardware environment is stripped of
> all the complexity that can be reasonably disposed of.
>
>

Software is easiest to change, but not easiest to change correctly. Ask the
electrical engineer how he would like to build a computer motherboard given
that he has to fabricate all his own components by hand using his own silicon
foundary and only the minimum automation. Ask him how he'd like to build his
own chips, even his own resistors and boards. Ask him how he'd like to formulate
his own solder. That's what we have to do all the time. There are no available,
accessible, reliable catalogs of software components for the average software
developer.

As for tools, at the EE has his oscilliscopes and meters and analysis tools.
What does a software developer have? Usually just a compiler, linker, and
if he's extremely lucky, a debugger (and if he's *really* lucky it might be
a source level debugger).

If EEs had to deal with the level of available tools and components that
software developers did, they'd be a little more unpredictable in their
schedule too.

-----------------------------------------------------------
David W. Griffin | Martin Marietta Corp
grif...@escmail.orl.mmc.com | Orlando, Florida
(407)826-3697 | Posts are my opinions only

Dave Berry

unread,
Nov 28, 1994, 10:51:37 AM11/28/94
to
ka...@audio.esd.sgi.com (Bruce Karsh) writes:
>But all this hardware-engineering envy is really misplaced. Software
>engineers are making great products and the hardware engineering
>profession has a lot to learn from us.

I would like to learn of positive differences as well as negative ones.
Please say more.

Dave Berry

unread,
Nov 28, 1994, 10:42:24 AM11/28/94
to
tk...@pipeline.com (Tony Karp) writes:
>A software project is joint development of intellectual
>property. Other engineers work on tangible things. Like bridges
>and airplanes.

Apparently electronic engineers have been known to use this argument to
distinguish their field from mechanical and civil engineering. The claim
is that you can see the forces in a bridge or aeroplane, but not in an
electronic circuit. In actual fact, you can't see the forces involved
even in civil engineering -- you can only see the structures that bear them.
The person with whom I was talking when I this topic came up made just this
point when arguing that managing software is not much different from
managing hardware.

Jorge L. Boria

unread,
Nov 28, 1994, 4:39:44 PM11/28/94
to
A couple of coins in the fountain:

1. Vertical Specialization
Engineers have different skills and they are all recognized as valuable.
Even in the same branch, road-builders usually differ from bridge builders
and skyscraper builders.

2. Sequential Specialization
In different parts of a project, specially large (and therefore risky)
projects, different specialsits are brought into play. The typical "1
person, 1 project" management technique used by many in SW Eng is unthought
of in other engineering disciplines.

3. Accountability
Different documents from the design process are required by the
engineering process in many disciplines, and those producing them are
accountable for them. Since we can usually (but not always) get away with a
poor requirements document, accountability dissapears in a sea of finger
pointing.

So I figure I envision a mature SW engineer profession when people will say
things such as: "I have a license for developing the interface designs for
user-oriented word processors, but I am studying towards a general
practitioner diploma", or "Yeah, the company closed because they heeded
their lawyers and kept their disclaimers, so nobody bought their products
anymore". Just dream on, baby!

The opinions afore expressed are solely the responsibility
of JLB and in no manner commit policy of my employer
/
__/
(__)

Tony Karp

unread,
Nov 28, 1994, 6:29:58 PM11/28/94
to

Another way that software is different from...

Software is more subject to catastrophic failure than most
other things. While other things may fail catastrophically, it
is far more common in software.

There are many ways that software is different. I think that it
important to try and recognize these differences and gain some
understanding from them.

It's about understanding what we do.

So please don't respond by saying that thus and such other
thing is also subject to catastrophic failure.

The real question is what would you do if your car misbehaved
as often as your computer?

Gerald Serviss

unread,
Nov 28, 1994, 7:05:54 PM11/28/94
to
Bruce Karsh <ka...@audio.esd.sgi.com> wrote:
>
>I'm getting tired of all the negativity about software.

Software development as a job description
is at best 50 years old. Considering that electrical engineering is perhaps
100 years old, we are young and very young compared to say bridge building.

>
>There are a lot of software-based products on the market. For the most
>part, they perform quite well, and customers love them and buy them at a
>rate that's really amazing.

Yes, this is true but we would be strained to be like say an auto
maker offering tons of options and colors ... on those million shipped
units. The software that you are taking about is relatively simple as
compared to the most complex stuff (telephony systems, air traffic control
etc)

>
>Meanwhile I can't turn on my TV without hearing about the failures of the
>hardware engineers. The Pentium chips CPU doesn't divide correctly,
>Ford pickup trucks explode on impact, Chrysler Minivans doors don't
>latch safely, airplanes keep crashing.
>

There are lots of stories about software failures:

The Denver Airport
Space Shuttle problems
Telephone System Outages
Satellites being misaimed by software
medical equipment that maims or kills rather than heals
The inability of the FAA to replace the current air traffic control sys

and the list goes on...

The issue that is being missed here is that the large software projects
that are undertaken today are the most complex 'machines' ever built by
humankind. Would you have felt safe with your code orbiting the planet
and controlling weapons of mass destruction ? I don't think that I would
have.

>There's plenty of problems with hardware engineering. In comparison,
>software engineering is not doing a bad job. Software engineers regularly
>crank out very good products at a very reasonable development cost. I look
>forward to a time when software engineers can do an even better job than
>they do now.

A bad job as compared to what standard ?

Why are 50% of all projects started are canceled and why are
most projects late and overbudget.

We are doing a good job considering the tools that we are have and
considering that there are no laws of physics to guide us.
The bottom line is that good is the enemy of better and we should not
think ourselves so good that we forget that we have a long way to go.


--
-------------------------------------------------------+-----------------------
Democracy is where you can say what you think even | Jerry Serviss
if you don't think. | Motorola Inc
| ser...@cig.mot.com

Tony Karp

unread,
Nov 29, 1994, 5:52:23 AM11/29/94
to

Here is another way that software is different.

Software is subject to unexpected and often disastrous side
effects.

While other things may occasionally exhibit side effects, this
is a way of life with software.

Seemingly innocent changes produce unexpected results.

This effect can be so bad that some bugs may be intentionally
left in rather than introduce new ones in the attempt to fix
the existing ones.

Patrick D. Logan

unread,
Nov 29, 1994, 3:40:08 AM11/29/94
to
In article <3b61ri$1...@nntp.interaccess.com> Guy A. Lyle
<gl...@interaccess.com> writes:

>Please consider the relative youthfulness of the software engineering
>"profession" compared to that of electrical or mechanical engineering.
>We are "not very good" because our branch of engineering has yet to
>establish reliable, repeatable processes.

What I am saying is that most software developers with CS degrees that I know
are either ignorant of what we know *already* about developing software or
incapable of applying that knowledge well.

Gary GW Hicks

unread,
Nov 29, 1994, 1:19:45 PM11/29/94
to

>In article <3b61ri$1...@nntp.interaccess.com> Guy A. Lyle
<gl...@interaccess.com> writes:
>
>>Please consider the relative youthfulness of the software engineering
>>"profession" compared to that of electrical or mechanical engineering.
>>We are "not very good" because our branch of engineering has yet to
>>establish reliable, repeatable processes. Many of us got into the ball
>>game with degrees in things other than software engineering (such degrees
>>didn't exist to begin with!).
>
>I'm getting tired of all the negativity about software.
>

I'm getting tired of all the negativity, period. I think the point being made
was that as a profession, Software Engineering is a toddler compared to other
engineering diciplines (e.g. architechual, electrical).

>
>There's plenty of problems with hardware engineering. In comparison,
>software engineering is not doing a bad job.
>

Yes, but is software engineering doing a good job? Yes AND no. I have experience
in both hardware and software. There are parts of each dicipline that are good
and parts that are bad (or should I say immature).

Remember, I'm not saying ANY discipline is better, I'm saying that SOME are more
mature.

Every dicipline will have its failures. Mainly because they are populated by
human beings. Pointing out failures of others doesn't do anyone any good unless
the act of pointing things out helps fix the dicipline that failed, or improves
the dicipline that recognized the problem.

Hardware/Software - who cares? The point is that we need to do things better.
As human beings, we learn from trial and error. It makes sense to look at
more mature engineering diciplines - to avoid their errors - to make the software
engineering dicipline better.

Just as there are less and less buildings collapsing under their own weight or
burning down to the ground - because the respective diciplines have learned over time,
so too must the software engineering dicipline learn.

It takes guts to look at yourself (or your dicipline) with a truely critical eye
to change things for the better. Think about it. What we're really talking
about is evolution. Whether species or dicipline, neither will survive without
change.

No matter what we do, we all STILL need to get better at it. Instead of bickering
over who is better than who, we should ALL be saying "Hey everybody! This worked
out good. Can you use it?" Otherwise, we're all doomed to extinction.

As we depend upon software for more and more, I think it natural that the discipline
become more *diciplined*. I say, grab it and go with it. Then perhaps we'll all win
in the long run.

GW Hicks


Terry Bollinger

unread,
Nov 29, 1994, 4:57:48 PM11/29/94
to
Hi folks,

Assertion:

When it comes to techniques for designing extremely complex systems,
the software community is significantly more capable and mature than
traditional engineering disciplines such as electrical engineering.

Rationale:

Most claims that compare engineering to software development compare
the wrong activities. In particular, if you factor out the important
but quite distinct materials-related issues and focus purely on how
developers handle extremely high levels of logical complexity -- the
one feature that carries over directly in both disciplines -- then it
would appear that chip designers were still writing bump-in-the-nigh
awful spaghetti code such random-line mask layouts decades after the
software community had learned to use modularity to control complexity
for comparably complex design problems.

Indeed, much of the progress in chip design in resent years has come
as a direct result of the chip community adopting such software based
approaches as high level design languages and silicon compilers. Had
the chip community not borrowed these techniques from the more mature
field of software design, the current level of complexity in advanced
chips such as the Pentium simply would have been impossible.

Debate, anyone? }=-)>

Cheers,
Terry Bollinger

roge...@hnlv4.verifone.com

unread,
Nov 28, 1994, 10:49:44 PM11/28/94
to
Guy A. Lyle writes:
>
>Please consider the relative youthfulness of the software engineering
>"profession" compared to that of electrical or mechanical engineering.
>We are "not very good" because our branch of engineering has yet to
>establish reliable, repeatable processes.

Which, in turn, is because we don't yet have mature technology. By
technology I don't mean tools and design methods; I mean an established
body of knowledge about the right way to build things. Given the need
to design a veebleflexor, most engineers can go to handbooks, etc. and
find out how veebleflexors are built. He will choose among various
well-understood alternatives for the veebleflexor subsystems. And he
will probably add a little bit of creative innovation to make this one
just right for his particular customer.

But a software engineer designing, oh let's say, an airport baggage
handling system, typically starts out with a blank sheet of paper and the
hope that the lack of solid application knowledge can be compensated for
by pure methodology. I view the CMM as basically an attempt to force the
outward trappings of a mature process onto an immature technology. This
may not be a bad thing to do while waiting for the technology to evolve,
but I am very skeptical that truly fundamental improvement will come from
this path.

As an exception which proves the rule consider compiler design. Here there
is a well-established body of theory and practice, and in my experience
compiler projects generally go pretty smoothly and produce relatively
trouble-free products compared to other software of comparable size and
complexity. As far back as "The Mythical Man-Month" Fred Brooks observed
that "The flaws in design and execution pervade expecially the control
programs, as distinguished from the language compilers." Also, "Some of
the compiler teams in the OS/360 effort were building their third or fourth
systems, and the excellence of their products shows it."

We will get reliable baggage handling software the third or fourth time
around, or when the designers can consult the "Handbook of Baggage Handling
System Software". Until then we seem to be stuck with doing our best to
substitute management for knowledge.

- Roger Miller
VeriFone, Inc.
roge...@verifone.com

Thomas E Janzen

unread,
Nov 29, 1994, 8:43:25 PM11/29/94
to
There will never be a textbook on building software systems for baggage
handling systems. I would be surprised to find a textbook on building
baggage handling hardware. Software is being applied to so many new and
innovative applications every day that they variety of applications is
indefinitely large. Principles can be discovered and invented, thus
real-time studies, compiler technology, numerical analysis. But the
increasing variety will continue to grow. This is why it is
important to have domain
experts and software experts who can communicate during requirements
analysis. Domain experts are the worst coders in the world (unless the
domain is CASE, or even then). But they are needed to define products.
And yet,
scientific companies who need first- or second-rate s/w engineers hire
2nd-rate scientists (4-th rate s/w developers) to write software in the
belief that scientific knowledge is more important than s/w knowledge
when writing real-time code.
A complete requirements analysis embodies the domain knowledge required
for the project (but of course training in the domain helps the developers).

Denver of course had management problems and
last-minute changes from a johnny-come-lately but key customer.
The Therac-25 had a h/w problem: they removed the h/w interlocks.

--
Tom Janzen - t...@world.std.com USA Distributed Real-Time Data Acquisition S/W
for Scientists and Engineers using *nix, C, C++, X, Motif, Graphics, Audio
See my video Dilettante at the DeCordova near Boston to December 7 94

Bruce Karsh

unread,
Nov 29, 1994, 10:19:45 PM11/29/94
to
In article <3bdr92$p...@delphinium.cig.mot.com> ser...@tazdevil.cig.mot.com (Gerald Serviss) writes:

>There are lots of stories about software failures:
> The Denver Airport

Plagued by hardware, software, and management problems.

> Space Shuttle problems

The Challenger explosion was a hardware problem.

> Telephone System Outages

Far more often a hardware problem than a software problem.

> Satellites being misaimed by software

There is no evidence that the Mars explorer lossage
was anything but a hardware failure.

> medical equipment that maims or kills rather than heals

Are you refering to the Therac? It had both hardware and software
problems and if the hardware had functioned properly, there might
not have been any casualties. A faulty sensor design is not a
software failure.

By the way, the Therac was a project lead by hardware engineers,
and done by a hardware company, apparently with almost no
involvement from people knowledgable about software. While the
machine was killing people, there was nobody at the factory who
had even a clue that software was vaguely involved. Apparently,
the Therac hardware folks thought it was OK to have just one guy
do ALL the software. I don't think serious software is done that
way in very many places and I don't think that software should
be blamed for the bad work of a bunch of clueless hardware
designers.

> The inability of the FAA to replace the current air traffic control sys

How is this a software problem?

> and the list goes on...

Keep trying. So far, you have listed quite a few HARDWARE
failures.

You forgot the Pentium floating point bug.

Ben Last

unread,
Nov 29, 1994, 8:07:52 AM11/29/94
to
In article <3b32f0$s...@pipe2.pipeline.com> tk...@pipeline.com "Tony Karp" writes:

>Here's another thing that's different about software.
>
>It can only be fixed by the manufacturer. This is truer for
>software than for most other products.

Hmmm...

>If your TV or VCR or car breaks, you can probably get it fixed
>locally.

Right; they'll swap the board for a spare that they keep. They won't open
up the chips and fix the silicon.

>Not so with software. If MS Word is broken only Microsoft can
>fix it.

Or send you a patch; the software equivalent of swapping the board.

>Can anyone point out the implications of this?

Yes; modern digital hardware boards have quite a lot in common with
software.

regards,
ben

--
--------------------------------------------------------------------------
| Ben Last, Fisons Instruments | (All postings are personal, and not the |
| b...@vgdata.demon.co.uk | opinions of Fisons Instruments) |
--------------------------------------------------------------------------

kr...@minster.york.ac.uk

unread,
Nov 30, 1994, 12:51:57 PM11/30/94
to
================================================================
In article 19261 of comp.software_eng tk...@pipeline.com (Tony Karp) wrote:-

Here is another way that software is different.

Software is subject to unexpected and often disastrous side
effects.

While other things may occasionally exhibit side effects, this
is a way of life with software.

Seemingly innocent changes produce unexpected results.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This effect can be so bad that some bugs may be intentionally
left in rather than introduce new ones in the attempt to fix
the existing ones.

===================================================

One reason for this, possibly the main reason, is that these changes are not viewed from the perspective of theh whole machine. If they were, some of them wouldn`t be considered as LITTLE changes. It depends on the importance (criticality ) of that part of the code to the whole. If it is obvious, then it is trated with respect. All too often it is not obvious.

An analogy:
Lets say someone is asked to make a modification to a wheel and tyre, and lets say that the person making the change decides that a remould tyre could replace the existing high performance tyre (they have to be safe up to the legal speed limit to be allowed to be sold after all). The tyre fits well and it rolls properly when tested (module test).

Now it so happens that this tyre and is fitted to a Ferrari. Whilst the driver uses the car around town it works OK. When it is driven on motorways at speeds up to say 10 mph above the legal limit it performs OK. But when the driver starts driving hard on some twisty country road the tyre fails, because it was not designed to cope with the expected cornering loads of a Ferrari.

Now the obvious warning sign for the mechanic was that the existing tyre had a high performance rating. The mechanic should have checked whether the replacement tyre should also have been up to the same specification. This was the important information.

Now consider a maintenance change to a software program. There (typically) is nothing in the comments within the code to say how critical it is to the system as a whole, or which other parts of the system use it. This information may be available in design information. In which case it should be studied and the implications identified. Ideally the modifications should be applied to the system design, then the subsystem design and finally to the code itself.
All to frequently modifications are performed and considered at the code level and not the system level.

If the code had been generated automatically by a tool from a design produced in that tool, then the modification would have been made to the design and the design itselfas well as the automatically generated code would have be tested for consistency and pre-determined other factors. Thus increasing the chances of a safer correction and upto date design information being available. (Yes I know tools also have flaws in them.)

I hope this helps,

Kearton
*************************************************************************
Kearton Rees kr...@cs.york.ac.uk
High Integrity Systems Engineering Group, Tel.: 01904-433387
Computer Science Dept., Fax.: 01904-432708
University of York,
Heslington Road,
York, YO1 5DD

At other times:
K.R...@axion.bt.co.uk
Ipswich Software Engineering Centre,
G24, SSTF Building, BT Labs., Tel.: 01473-642810
Martlesham Heath, Ipswich, IP5 7RE Fax.: 01473-643019
*************************************************************************

Gerald Serviss

unread,
Nov 30, 1994, 12:51:04 PM11/30/94
to
In article <3bgr0h$6...@gazette.engr.sgi.com>,

Bruce Karsh <ka...@audio.esd.sgi.com> wrote:
>In article <3bdr92$p...@delphinium.cig.mot.com> ser...@tazdevil.cig.mot.com (Gerald Serviss) writes:
>
>>There are lots of stories about software failures:
>> The Denver Airport
>
> Plagued by hardware, software, and management problems.

But, these are the problems of software. This issues are shifting
requirements and the inability of the software developers to adapt to
those changes. Changing requirements are a fact of life and we as
software developers need to deal with them.

>
>> Space Shuttle problems
>
> The Challenger explosion was a hardware problem.

Did I say Explosion ? What about all the processor synchronization problems
that had plagued the program initially ?

Also, the cost of producing the shuttle software is outrageous. I hardly
consider this a success ?

>> Telephone System Outages
>
> Far more often a hardware problem than a software problem.

Sorry pal. This IS my business and the fact is that most telephone
system outages today are caused by software problems. This is of course
discounting cases where cables are cut by some dumb excavation contractor.

The last major nation wide outage (East Coast and West Coast on 2 consecutive
days in 1991 I think) was caused by flawed software in the signal transfer
points.

In fact it was a single branch instruction that was wrong.

>
>> Satellites being misaimed by software
>
> There is no evidence that the Mars explorer lossage
> was anything but a hardware failure.
>

As I recall it was also the mission control software that allowed someone
to do something with a valve that was suggested as the cause of the loss.

Perhaps this is the case, but I just read about a satellite that was going
to the moon as part of an SDI targeting experiment that had an 11 minute
booster burn instead of a couple of seconds. This WAS a software problem.

>> medical equipment that maims or kills rather than heals
>
> Are you refering to the Therac? It had both hardware and software
> problems and if the hardware had functioned properly, there might

Ok , so perhaps you caught me on one. But, this is a problem of software
development. Give some smart guy a computer, and a compiler and poof you
have a software engineer. Hey, anybody can write code... Right ?

>> The inability of the FAA to replace the current air traffic control sys
>
> How is this a software problem?
>

The air traffic control system is based on lots of software and the FAA has
scaled back the project from a full replacement to simply trying to replace
the displays that the controllers use. If I recall correctly the project
is many years behind.

>> and the list goes on...
>
> Keep trying. So far, you have listed quite a few HARDWARE
> failures.

I don't agree.

>
> You forgot the Pentium floating point bug.

I thought about that too. As I recall reading this is a bug in the
microcode. So, in fact it is a software problem and not a hardware problem.

Lets expand on this (apparently) PC based thinking that you are using.

Lets look at Microsoft the giant of the industry. What have they done
lately:

NT is a huge disappointment in the market and it was at
least a year late. It was also very buggy from the start.

Windows 95 (Chicago) is also a year late, and I am sure that
it will have tons of problems.

I could go on but what is the point ?

I'll tell you what the point is:

We as developers need to find ways of quickly and accurately
capturing requirements and converting them into products that
are virtually flawless.

If we sit back and say that what we do is good enough someone
is going to step in and eat our lunch. This has been proved
time and time again in all business; hardware, software and services.

The producer who can spin the best mix of cost, quality and on time
delivery will win every time.

Bruce Karsh

unread,
Nov 30, 1994, 2:56:07 PM11/30/94
to
In article <3bie28$n...@delphinium.cig.mot.com> ser...@tazdevil.cig.mot.com (Gerald Serviss) writes:

>> Plagued by hardware, software, and management problems.

>But, these are the problems of software. This issues are shifting
>requirements and the inability of the software developers to adapt to
>those changes. Changing requirements are a fact of life and we as
>software developers need to deal with them.

I don't understand what you are saying here. Are suggesting that hardware
and management problems are "problems of software"? How so.

>> The Challenger explosion was a hardware problem.
>
>Did I say Explosion ? What about all the processor synchronization problems
>that had plagued the program initially ?

The software problems that the shuttle has had have had the effect of
delaying some flights. The hardware problems have killed people and
have caused billions of dollars in damage.

Nobody would claim that there are no software problems. But the software
looks to be pretty darn good, compared to the hardware.

>Also, the cost of producing the shuttle software is outrageous. I hardly
>consider this a success ?

Outrageous? Compared to what? They spend a fortune on hardware.

>Sorry pal. This IS my business and the fact is that most telephone
>system outages today are caused by software problems. This is of course
>discounting cases where cables are cut by some dumb excavation contractor.

The most common causes of system outages that I see are caused by
utility pole problems - a hardware problem. Contractors digging up
cables is another big problem.

There was an enormous service outage in Chicago a few years ago. It
was caused by a fire - a classic hardware problem. The inadequate fire
supression system was not a software problem.

>> There is no evidence that the Mars explorer lossage
>> was anything but a hardware failure.

>As I recall it was also the mission control software that allowed someone
>to do something with a valve that was suggested as the cause of the loss.

I haven't heard this. But if it's true, then are you suggesting that blame
for operator error should now be assigned to software? My understanding
is exploded. Why did the hardware engineers make an exploding satellite?

>Perhaps this is the case, but I just read about a satellite that was going
>to the moon as part of an SDI targeting experiment that had an 11 minute
>booster burn instead of a couple of seconds. This WAS a software problem.

Nobody would suggest that software doesn't fail. But its reliablity, compared
to other aspects of a complex system, is not all that bad.

>Ok , so perhaps you caught me on one. But, this is a problem of software
>development. Give some smart guy a computer, and a compiler and poof you
>have a software engineer. Hey, anybody can write code... Right ?

The attitude that you present is a big problem among hardware organizations
who try doing software for the first time. Fortunately, there are Darwinian
forces at work that tend to rapidly rid the world of organizations who
maintain that attitude.

>The air traffic control system is based on lots of software and the FAA has
>scaled back the project from a full replacement to simply trying to replace
>the displays that the controllers use. If I recall correctly the project
>is many years behind.

It's also based on lots of hardware and lots of politics.

>> Keep trying. So far, you have listed quite a few HARDWARE
>> failures.
>I don't agree.

Let's see:

1. The Denver Airport situation involves significant hardware problems,
2. Satellite failures are usually hardware failures,
3. Phone outages are often hardware failures,
4. The Therac deaths involved a hardware failure.

There's plenty of blame to go around and the hardware guys are at least as
at fault as the software guys. The notion that software is somehow more
prone to serious failure than hardware just is not borne out by experience.
Too many people die because of hardware failures.

>> You forgot the Pentium floating point bug.
>I thought about that too. As I recall reading this is a bug in the
>microcode. So, in fact it is a software problem and not a hardware problem.

Sorry, it's apparently not a microcode bug.

> NT is a huge disappointment in the market and it was at
> least a year late. It was also very buggy from the start.

Engineering projects which try to break new ground are often late. So
what? I don't think it's very hard to come up with a list of late hardware
projects.

> We as developers need to find ways of quickly and accurately
> capturing requirements and converting them into products that
> are virtually flawless.

It'd be great to come up with a means for making virtually flawless products,
but I doubt that it'll happen in my lifetime. The idea of a "flawless"
product is something that people can only concieve of in software. No
hardware product will ever be flawless.

Instead of using flawlessness as a criteria, how about using criteria like
usefullness,
reliability,
affordability,
durability,
performance,
time to market.

Software does pretty well under these criteria.

> If we sit back and say that what we do is good enough someone
> is going to step in and eat our lunch. This has been proved
> time and time again in all business; hardware, software and services.

The question is not whether what we do is good enough. The question is
whether all the negativity about software compared to hardware is
justified. Are large software systems more prone to failure than
hardware systems? There are a lot of hardware engineers who would like
us to believe that this is the case. But the truth is that most serious
system failures are hardware failures and there are plenty of examples of
large software systems which work well.

> The producer who can spin the best mix of cost, quality and on time
> delivery will win every time.

Exactly right. And suppliers can often gain a big advantage in these areas by
using software instead of hardware.

Guy A. Lyle

unread,
Nov 30, 1994, 11:38:38 PM11/30/94
to
In article <patrick_d_loga...@ccm.jf.intel.com> Patrick D.

Logan, patrick...@ccm.jf.intel.com writes:
>What I am saying is that most software developers with CS degrees that I
know
>are either ignorant of what we know *already* about developing software
or
>incapable of applying that knowledge well.

Yes, I have noticed the same thing. My theory is that most people who
enter
the work force from college learn how to perform their work from the
people
they work with. Of that meshes with what they learned in college, fine.
If it doesn't, being the "new kids on the block", they adopt the ways of
their "more experienced" bretheren. When those bretheren do not have
experience or appreciation for new tools and methodologies, guess what
happens. To repeat a rather famous quotation, "I have seen the emeny, and
he is us!" :-)

Guy Lyle
************************************************
*** Guy A. Lyle (gl...@interaccess.com) ***

*** Lake Zurich, IL, USA ***
************************************************

george kambic

unread,
Dec 1, 1994, 8:55:35 AM12/1/94
to
In article <3bie28$n...@delphinium.cig.mot.com>, ser...@tazdevil.cig.mot.com (Gerald Serviss) writes:
|> In article <3bgr0h$6...@gazette.engr.sgi.com>,
|> Bruce Karsh <ka...@audio.esd.sgi.com> wrote:
|> >In article <3bdr92$p...@delphinium.cig.mot.com> ser...@tazdevil.cig.mot.com (Gerald Serviss) writes:
|> >>There are lots of stories about software failures:
|> >> The Denver Airport
|> > Plagued by hardware, software, and management problems.
|> But, these are the problems of software. This issues are shifting
|> requirements and the inability of the software developers to adapt to
|> those changes. Changing requirements are a fact of life and we as
|> software developers need to deal with them.

There are some ways to deal with them. Were changes allowed in the contract?
No? Then tough patooties. Changes are allowed? Then let's renegotiate.
Changing requirements are a fact of life, but *someone* allows those
changes in. Sounds like a people problem to me.

|> >> Space Shuttle problems
|> > The Challenger explosion was a hardware problem.
|> Did I say Explosion ? What about all the processor synchronization problems
|> that had plagued the program initially ?
|> Also, the cost of producing the shuttle software is outrageous. I hardly
|> consider this a success ?

You may not. I suspect that most astronauts on board might differ with
you (IMHO of course). Man-rated software is hardly what you find for
sale in computer stores. Do you mind if I disagree with your definition of
success? In addition, there are at least two reports now out on the
Shuttle software that at least bear reading. No they ain't perfect,
but they's trying. Sematech Tech Transfer report 94092551A-TR: A Case
History of the Space Shuttle Onbard System Project.

|> >> Telephone System Outages
|> > Far more often a hardware problem than a software problem.
|> Sorry pal. This IS my business and the fact is that most telephone
|> system outages today are caused by software problems. This is of course
|> discounting cases where cables are cut by some dumb excavation contractor.

How many outages are we talking about here. The published ones or
the unpublished ones. Could we please have some data?

|> The last major nation wide outage (East Coast and West Coast on 2 consecutive
|> days in 1991 I think) was caused by flawed software in the signal transfer
|> points.
|> In fact it was a single branch instruction that was wrong.
|> >> Satellites being misaimed by software
|> > There is no evidence that the Mars explorer lossage
|> > was anything but a hardware failure.
|> As I recall it was also the mission control software that allowed someone
|> to do something with a valve that was suggested as the cause of the loss.
|> Perhaps this is the case, but I just read about a satellite that was going
|> to the moon as part of an SDI targeting experiment that had an 11 minute
|> booster burn instead of a couple of seconds. This WAS a software problem.

There have been software problems in targeting sattelites. There also
have been a few successes. The pioneer flights past Uranus and Pluto
for example.

|> >> medical equipment that maims or kills rather than heals
|> > Are you refering to the Therac? It had both hardware and software
|> > problems and if the hardware had functioned properly, there might
|> Ok , so perhaps you caught me on one. But, this is a problem of software
|> development. Give some smart guy a computer, and a compiler and poof you
|> have a software engineer. Hey, anybody can write code... Right ?

I am becoming totally unsure of your point here. Does the software industry
have problems? Yes. Is it responsible for every failure in the world? No.
What's your point?



|> >> The inability of the FAA to replace the current air traffic control sys
|> > How is this a software problem?
|> The air traffic control system is based on lots of software and the FAA has
|> scaled back the project from a full replacement to simply trying to replace
|> the displays that the controllers use. If I recall correctly the project
|> is many years behind.
|> >> and the list goes on...
|> > Keep trying. So far, you have listed quite a few HARDWARE
|> > failures.
|> I don't agree.

I noticed. So why don't you attempt to establish a basis for agreement
rather than assuming that everyone accepts your definition of everything
being a software failure.

|> > You forgot the Pentium floating point bug.
|> I thought about that too. As I recall reading this is a bug in the
|> microcode. So, in fact it is a software problem and not a hardware problem.
|> Lets expand on this (apparently) PC based thinking that you are using.
|> Lets look at Microsoft the giant of the industry. What have they done
|> lately:
|> NT is a huge disappointment in the market and it was at
|> least a year late. It was also very buggy from the start.
|> Windows 95 (Chicago) is also a year late, and I am sure that
|> it will have tons of problems.

I know. Microsoft will be out of business by June of 1995.
You can bet on it.

|> I could go on but what is the point ?
|> I'll tell you what the point is:
|> We as developers need to find ways of quickly and accurately
|> capturing requirements and converting them into products that
|> are virtually flawless.
|> If we sit back and say that what we do is good enough someone
|> is going to step in and eat our lunch. This has been proved
|> time and time again in all business; hardware, software and services.
|> The producer who can spin the best mix of cost, quality and on time
|> delivery will win every time.

Thank you for absolving marketing, management, customers, systems
analysts, and everyone else of any responsibilities.

--
George X. Kambic Allen-Bradley
George...@ab.com 747 Alpha Drive
"Standard Disclaimer" Highland Heights, OH 44143
V: 216.646.3269
F: 216.646.4343

There is a theory which states that if ever anyone discovers
exactly what the Universe is for and why it is here, it will
instantly disappear and be replaced by something even more
bizarre and inexplicable.

There is another which states that this has already happened.

roge...@hnlv4.verifone.com

unread,
Dec 1, 1994, 12:23:09 AM12/1/94
to
In Article <3b73hc$k...@gazette.engr.sgi.com>

ka...@audio.esd.sgi.com (Bruce Karsh) writes:
>
>I'm getting tired of all the negativity about software.
>
>There are a lot of software-based products on the market. For the most
>part, they perform quite well, and customers love them and buy them at a
>rate that's really amazing.
>
>Meanwhile I can't turn on my TV without hearing about the failures of the
>hardware engineers. The Pentium chips CPU doesn't divide correctly,
>Ford pickup trucks explode on impact, Chrysler Minivans doors don't
>latch safely, airplanes keep crashing.

The telling point is that these failures are so unusual that they get
worldwide press coverage. Software will be in the same category when
you turn on your TV and hear:

Software industry giant Microsoft today admitted that a bug has
been discovered in Word 8.3, the latest release of its popular
document processing program. The problem causes the spelling
checker to sometimes fail to report spelling errors in words
containing more than 23 characters which are hyphenated across
a page break.

The news spread quickly among users, who reacted with shock
and anger. It is estimated that it will cost Microsoft over
7 million dollars to recall and replace all the defective
products.

Mike Kelvin

unread,
Dec 1, 1994, 6:11:00 PM12/1/94
to
TO: ka...@audio.esd.sgi.com


K>Meanwhile I can't turn on my TV without hearing about the failures of
K>the hardware engineers. The Pentium chips CPU doesn't divide
K>correctly, Ford pickup trucks explode on impact, Chrysler Minivans
K>doors don't latch safely, airplanes keep crashing.
K>There's plenty of problems with hardware engineering. In comparison,
K>software engineering is not doing a bad job. Software engineers
K>regularly crank out very good products at a very reasonable
K>development cost. I look forward to a time when software engineers
K>can do an even better job than they do now.

This works for me. But then shouldn't we create for our profession a
unique paradigm, rather than try to steal the mantle of the hardware or
should we call them applied, or inorganic engineers, who are not so
great after all? And look at the time it took them to get where they are
now. May be once we will have been in business as long as they were, we
can crash planes with the same alacrity. Perish the thought.
---
. CMPQwk #1.4. UNREGISTERED EVALUATION COPY

----
Digitec Online - South Africa
Telnet: bbs.digitec.co.za or 196.11.62.106

Bill Gage

unread,
Dec 2, 1994, 5:37:08 PM12/2/94
to
In article <3bg84s$k...@sun094.dsccc.com> Terry Bollinger,
tbol...@spd.dsccc.com writes:
>
>Assertion:
>
> When it comes to techniques for designing extremely complex systems,
> the software community is significantly more capable and mature than
> traditional engineering disciplines such as electrical engineering.

I agree. When you look at the problem areas where people are using
software to develop solutions, they often are ones that can't be
addressed by any other technology. The problem areas are complex,
require adaptive responses, must be evolvable as the problem domain
becomes better understood through use, etc. Much of this discussion of
software vs hardware, software engineering vs civil engineering, etc. is
comparing apples to oranges. Show me the telephone switching system
implemented totally in hardware, with the same level of functionality
that we have today in public stored programme controlled switches, and
THEN we can argue about which is the better discipline.

Why are we arguing about whether hardware has more problems than
software or whether the hardware was at fault rather than the software?
I happen to be a perfectionist. I hate it when things don't work
properly ... and I hate it even more when it's software that I wrote
that doesn't work properly. The excuse that Joe Blow over there has even
more problems than I do is a cop-out.

You've all read the caveat emptor disclaimer in every PC software
package? Perhaps the immaturity of the software industry is actually the
immaturity of its practitioners.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Bill Gage _/ Internet: ga...@bnr.ca _/
_/ Bell-Northern Research _/ _/
_/ Ottawa Ontario CANADA _/ #include <std/disclaimer.h> _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Gary GW Hicks

unread,
Dec 5, 1994, 12:15:18 PM12/5/94
to

>>In article <3bg84s$k...@sun094.dsccc.com> Terry Bollinger,
>>tbol...@spd.dsccc.com writes:
>>
>>You've all read the caveat emptor disclaimer in every PC software
>>package? Perhaps the immaturity of the software industry is actually the
>>immaturity of its practitioners.
>>

I agree. However, I think it is a combination of both it's
practitioners *and* our industry.

GW Hicks


David Caswell

unread,
Dec 8, 1994, 9:33:59 PM12/8/94
to
patrick...@ccm.jf.intel.com (Patrick D. Logan) writes:

What I am saying is that most software developers with CS degrees that I know
are either ignorant of what we know *already* about developing software or
incapable of applying that knowledge well.

True. It's amazing how many people who think the problems they
are solving are unique and that there's nothing to be learned
from past experience.

In my experience, during the interview process for hiring
new employees most don't have the foggiest idea how to explain
how their education might be relevant to the job they're
seeking.

Now, I agree with the others that have said that a good
education is very important for someone who develops
software. At the same time, if an applicant for a job
doesn't think their education is relevant I'm not about
to try to change their mind.
--
-- Dave dcas...@pts.mot.com

0 new messages