🚀 go-pugleaf

In article <3579@eos.UUCP>, eugene@eos.UUCP (Eugene Miya) writes:
> In a nice article <11293@bloom-beacon.MIT.EDU> tada@athena.mit.edu 
> by Michael Zehr:
> >saving time building the application is more important than
> >reducing the running time of the application.  
> >but my experience on applications has led to the conclusion that a lot
> >of performance is being sacrificed for the decrease in application
> >building time.
> >
> >do others agree that this is a problem in the software industry, or it
> >is just me?  if it is a problem, how should we face it and fix it
> >before it becomes worse?
> 
> True. (on time and loss of some performance, by faster machines.)
> You cannot expect gains in performance and functionality at this time
> with combined gains in both hardware and software.  Just ask Xerox
> or Apple or NeXT.  There are many similar analogies in the physical world.
> 
> The real question is how much a user, builder is willing to change.
> Change is what software is all about.
> 
> You have no reason to be sorry,  you only get rid of those short-sighted,
> short-attention spanned people which our country is so notorious for
> producing (bad managers). ;)


EXTREMELY true!! A recent project I worked on had exactly this problem.
The project was years underway, and "almost" to beta, before someone
noticed "hey! this runs like a slow, fat pig!" So a performance czar
was appointed to magically fix everything. Naturally, he didn't since
the problems were built in to the design methodology. The attitude during
construction was "let's make it run; we can make version 1.1 run fast."
In spite of trying to get it shipped ASAP, we designed almost everything
from scratch, rather than using anything off-the-shelf that might save
us development time. This ended up contributing to our demise...

At this same company, after at least 10 years in the software business,
management (at least a small part of mgmt) was convinced that maybe we
ought to have a software library so the technology we created for one
project could be transferred to the next. This idea also died.

BTW, for an interesting perspective on those short-sighted, short attention
span bad managers, this month's Scientific American had another good article
on the state of american manufacturing and industry. One of the authors'
main points was that business today does not look toward long-term gains
and productivity, but toward short-term make a fast buck. While the article
covered all businesses, the analogy to much of today's s/w engineering is
obvious. How many times is the first (if not ONLY) priority to GET IT
SHIPPED! How ironic that these same managers often can't see the utility
in reusing existing tools.

Well, I've rambled long enough. Gotta earn that paycheck somehow...

Andrew L. Duane (JOT-7)  w:(508)-685-7200 X122  h:(603)-434-7934
Samsung Software America	 decvax!cg-atla!ginosko!duane
1 Corporate Drive			  uunet/
Andover, MA.   01810

Only my cat shares my opinions, and she's still learning "lint".