home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.org.eff.talk
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!gatech!emory!nastar!phardie
- From: phardie@nastar.uucp (Pete Hardie)
- Subject: Re: Software as PE
- Message-ID: <1993Jan5.154910.19144@nastar.uucp>
- Organization: Digital Transmission Systems, Duluth, GA.
- References: <889520164DN5.61R@tanda.isis.org> <1992Dec30.125324.27900@mksol.dseg.ti.com> <522322457DN5.61R@tanda.isis.org>
- Distribution: na
- Date: Tue, 5 Jan 1993 15:49:10 GMT
- Lines: 71
-
- In article <522322457DN5.61R@tanda.isis.org> marc@tanda.isis.org writes:
- > 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 |
-