Path: utzoo!attcan!uunet!mcsun!ukc!pyrltd!root44!praxis!itcp
From: itcp@praxis.co.uk (Tom Parke)
Newsgroups: comp.software-eng
Subject: Re: Development vs Engineering
Message-ID: <5466@newton.praxis.co.uk>
Date: 22 Oct 90 13:18:38 GMT
References: <5682@stpstn.UUCP> <1624@dschub.dsc.com> <123494@linus.mitre.org>
Organization: Praxis, Bath, UK
Lines: 41

mitchell@chance.uucp (George Mitchell) writes:

>In article <1624@dschub.dsc.com> cdk@neptune.dsc.com (Colin Kelley) wrote:
>`I see two problems which have kept software development from becoming an
>`engineering endevour:
>`
>`- Software is built on hardware.  And the hardware has been changing at a
>`  phenomenal rate.
>The instruction set architectures have not changed much more rapidly
>than the IC technologies.  HOL changes are slower yet.

As George points out the instruction set is not the problem, but that
does not mean there is no problem. The hardware *has* changed at a
phenomenal rate, the changes in processing power, memory and mass
storage continually re-write the rules for all those implementation
trade off decisions. They increase users expectations of what the
software should do for them. There are changes in networking and user
interfaces that give rise to considerations that didn't even exist ten
years ago. Finally because of hardware changes, where the hardware is
located, how it is used and who it is used by has all changed, these
all effect what the software has to do and how it does it.

Software is not actually usually built on hardware but on yet more
software. This too has changed phenomenally, but in fact offers some
salvation. Once a layer of software is good enough (eg. Unix, TCP-IP,
X, SQL) and sufficiently established and too expensive for most to
want to re-invent it, then it seems to offer some hope of actually
insulating us from the headlong rush of hardware development. Or at
least buffering up the hardware changes so it impacts developers less
frequently.

Elsewhere recently in this or a parallel stream, Brad Cox implied
software engineers were like civil engineers who re-invented the
brick every project. All too frequently perhaps its the software
engineer who's given a different brick and who has to re-invent the wall.

-- 

Tom Parke (my opinions and spelling are strictly temporary) 
itcp@praxis.co.uk
Praxis, 20 Manvers St., Bath BA1 1PX, UK