Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!umd5!eneevax!noise
From: noise@eneevax.UUCP (Johnson Noise)
Newsgroups: comp.software-eng
Subject: Re: Is it Art or is it Engineering
Summary: Good man
Keywords: Art Engineering Tolerances
Message-ID: <1232@eneevax.UUCP>
Date: 14 Feb 88 01:00:36 GMT
References: <6879@agate.BERKELEY.EDU> <3676@ihlpf.ATT.COM>
Reply-To: noise@eneevax.umd.edu.UUCP (Johnson Noise)
Organization: Elec. Eng. Dept., U of Maryland, College Park, MD 20742
Lines: 37

In article <3676@ihlpf.ATT.COM> warren@ihlpf.ATT.COM (Montgomery) writes:
>The question of whether software art or software engineering more
>correctly describes what software people do is age old.  While
>software development has aspects of both to it, I'd like to suggest
>that the dominant aspect for any large project is neither, it's
>management of complexity.
>
	I think you hit the <proverb-op1> right on the <proverb-op2>.

>In large systems, there are tasks that are clearly engineering. 
>Picking data structures and algorithms to achieve a desired level of
>fault tolerance is one that comes to mind, as is figuring out how to
>cope with widely varying loads with acceptible performance.  
>

	When people talk about complexity of a project, I give the
following example:

Unix distribution exec. size: > 30 Mbytes
Unix distribution source size: ~ 3 million lines (no comments)
Average programmer productivity: < 10 lines/programmer-working day

Total project size: ~ 1,200 programmer-years.

Clearly a big project.

>sources, etc.  A lousy product will be produced if the basic
>creative talent of the people who must supply it isn't up to the
>task.  The best printing and layout in the world won't sell a
>newspaper with poor writers.  Assuming that this is taken care of,
>though, the dominant concern is managing the thousands of individual
>tasks involved so that they come together when required to make a
>product.
>

	I'm glad to find at least one person who thinks clearly about
these things.