Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!ginosko!duane From: duane@ginosko.samsung.com (Andrew Duane) Newsgroups: comp.sw.components Subject: Re: a comment on Using components (also LONG) Summary: Performance, Managers, Style Message-ID: <1080@ginosko.samsung.com> Date: 11 May 89 13:48:21 GMT References: <11293@bloom-beacon.MIT.EDU> <3579@eos.UUCP> Organization: Samsung Software America, Inc. Lines: 59 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".