[
Lists Home |
Date Index |
Thread Index
]
Software copes with inputs by classifying them. Classification
fails when an unidentifiable event enters the pipeline.
Users of classifiers fail when they misidentify an event.
Between the mistakes the user can make and the events that
are not identifiable by the original design are many of the
failures of software engineering.
Issac Newton was an alchemist and a mathematician.
Albert Einstein was a patent clerk and a mathematician.
Note they were considered 'competent' scientists.
BTW: control system failures in fly-by-wire systems predate
Cali. The F-111A had a nasty habit when its terrain
following software actions contradicted the reflexes of the
pilot. The software and the wetware have to cooperate in
any real time system both at the level of inputs and the
acts of recognition. Because these are dynamic interactions
both in combinatorics and in the capability to produce
unknown-unknowns (new events that are beyond the range
of modeling), the safety margins are statistical, not real.
For that reason, experience is prized. Indemnity in
design is about making mistakes with knowns, not unknowns.
Still, some statements made in this thread about software
engineering are pertinent particularly if one changes
the title to 'computer scientist' and asks the question,
what of this IS *science*?
Try to sort out the terminology of a profession that
has consistently reinvented its concepts inconsistently
for over fifty years. If the next century is to produce
something really innovative, it may be a consistent
and maintainable science of applied computer technology.
Or not. 0 or 1. Choose. You have a chance of getting
that right.
len
-----Original Message-----
From: Michael Champion [mailto:michaelc.champion@gmail.com]
Sent: Saturday, January 01, 2005 11:20 AM
To: XML Developers List
Subject: Re: [xml-dev] [offtopic] The Airplane Example (was Re:
[xml-dev] Streaming XML)
On Sat, 01 Jan 2005 14:57:05 +0000, Bill de hOra
<bill.dehora@propylon.com> wrote:
> On the other hand trying to delineate what's engineering and what's
> alchemy in a software sense is no bad thing
I'm not sure I follow. To me, it's not clear what is alchemy and what
is engineering and what is computer science in the real world. The
Cali plane crash example seems to illustrate that -- the on-board
software worked as designed, and the design was rational, it just made
assumptions about a) the distribution of navigation beacons and b) the
attention to detail on the part of the pilots that turned out to be
over-optimistic. Is this engineering or alchemy? I'm not sure.
Benjamin Franz seems to think that best practices are clear and a good
process could have caught these unrealistic assumptions in advance.
Maybe, but I have a feeling that "best practice" is more of a
collection of hard lessons learned from investigating disasters, and
anticipating new flaws at the design phase is more in the realm of
alchemy than engineering. But maybe this is just a matter of using
slippery and value laden words in inconsistent ways, not real
disagreement.
But remember that Newton was an alchemist, and Kepler was an
astrologer :-) So, it probably is worth trying to delineate
engineering from alchemy, but I expect the line to be pretty fuzzy.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
|
