Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!njin!uupsi!ccavax!merriman
From: merriman@ccavax.camb.com
Newsgroups: comp.arch
Subject: Re: Bloat costs
Message-ID: <25444.2667fff8@ccavax.camb.com>
Date: 2 Jun 90 22:05:44 GMT
References: <640@sibyl.eleceng.ua.OZ> <2662CE6C.3E68@tct.uucp> <26798@eerie.acsu.Buffalo.EDU> <266576A7.6D17@tct.uucp>
Organization: Cambridge Computer Associates, Inc.
Lines: 34

In article <266576A7.6D17@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes:

[stuff deleted]

> 
> 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.
> -- 

Where I work (the New York financial community), it seems that maintenance
never ends. We are usually rushing to move an application from an old (hardware
and/or software) platform to a newer one before the old one runs out of steam
or falls apart, while tearing our hair out trying to keep the old system
running. These applications are always tangled up in some way with other
systems, many of which are not under any local control. Hardware is so much
cheaper than manpower that it is foolish to spend any time worrying about
saving a byte here or there. In fact, a lot of our maintenance headaches are
caused by scrimping on resources ("Why use a longword here instead of a word?
We'll never see a value of more than a few thousand." Ha!). Projects seem to be
a year late before they even get started. You may call this bad management, but
the forces driving the applications are beyond the control of the enterprise,
and probably beyond anyone's control. Straightforward, easy-to-maintain code is
of the utmost importance in this environment, especially considering that the
people who wrote the code are often long gone by the time you end up having to
fix something.

> Chip, the new t.b answer man    <chip%tct@ateng.com>,<uunet!ateng!tct!chip>


George Merriman, Cambridge Computer Associates