Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Tradeoffs
Message-ID: <9494@pt.cs.cmu.edu>
Date: 1 Jun 90 18:26:34 GMT
References: <640@sibyl.eleceng.ua.OZ> <2662CE6C.3E68@tct.uucp> <26798@eerie.acsu.Buffalo.EDU> <266576A7.6D17@tct.uucp>
Organization: Carnegie-Mellon University, CS/RI
Lines: 42

In article <266576A7.6D17@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>And I would like to know whether anyone agrees with Mr.
>Graham that "resource issues" are "short term" while
>"maintenance issues" are "long term."  Resources are used
>as long as you run a program; maintenance is over
>whenever you decide to stop maintaining it.  The latter
>often happens before the former.

The issue that connects these is cost-to-builder.  The resource
issues are mostly costs inasmuch as user [un]happiness will feed back
to the builder.  The maintenance issues are mostly costs measured in
the builder's effort spent, and in deadlines slipped.

Clearly, balancing such issues is a higher-level task.  I don't
presume to have hard rules: tradeoffs are best taught by example.  It
is perhaps the essence of engineering to trade off well, and the
essence of technology to readjust the balances, and to do end runs.

If posters would argue for small/simple/fast/etc, by giving actual
examples, I think that I for one would learn more.

Many years ago, Motorola brought out an 8-bit micro which only needed
+5V power.  Intel could have done the same, but they decided to beat
Motorola to market.  And that is why the 8080 needed multiple power
supply voltages - a pain to designers - and also a big part of why
the 8080 was the more successful product.  Time to market seems to
have been the right tradeoff, at that time and place.

There's a wonderful anecdote in "The Psychology of Computer
Programming" (G. Weinberg) about how a program has to work before
it's interesting whether it works fast.  I won't repeat it:  read the
book: you'll be glad you did.  However, I will repeat the counter
example, which Bill Wulf came up with.  He pointed out that he spent
a lot of time waiting for Scribe to run on his VAX 780.  Every
release of Scribe had various trivial, obscure bugs, which the
adventurous user (like Bill) would wind up discovering and hacking
around.  Now, suppose he was given a choice: Scribe Systems could put
out a flawless release: or they could put out one that ran twice as
fast.  Which would Bill choose?  Answer: the one which saved him the
most of his own time - the fast, flawed product.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science