Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.software-eng Subject: Re: Modifiability Message-ID: <1991Jun11.004620.3157@netcom.COM> Date: 11 Jun 91 00:46:20 GMT References: <1991Jun07.020546.29682@xstor.com> <1991Jun7.073448.11818@netcom.COM> <1991Jun10.155105.5816@auto-trol.com> Distribution: comp.software-eng Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 42 Earlier on this thread I posted a summary of a methodology that I have seen used on real projects and that results in modifiable and reusable code. In that posting, I said that one should tune for performance, but not let an obsession with performance pervert the architecture. In response, D.C.Sessions sent me some e-mail as follows (with permission to post and comment): > Something doesn't sound quite right here. While I agree that > microperformance is the bugaboo of small minds, I must take exception > with the notion that performance can IN ALL CASES be tuned in where > it wasn't designed in. > > Just as, in a hardware design, the basic architecture can make or break > a design (imagine using a Z80 for radar image analysis!), some software > architectural decisions can make acceptable performance impossible. By > the previous analogy, once you've designed in a Z80, all the clock > speedups and wait-state reductions in the world won't help. No argument. I was posting a summary, and as is the case with most summaries, some details were excluded that definitely need to be elaborated upon in a fuller discussion. I strongly agree that issues of macro-performance must be taken into account when designing the architecture--my remarks about performance tuning concern premature obsession with micro-efficiency issues when they can have no real impact on overall system performance. At every level of granularity of focus, from architecture down to coding individual lines, performance should be taken into account. The trick is to make sure that the proper KIND of performance issue is taken into account at the appropriate time. Worrying about register allocation peculiarities of this or that chip before you've settled on a networking scheme is silly. On the other hand, never worrying about such issues is sloppy, unless you have cycles to burn (and nobody ever does). One of the reasons I'm such a strong proponent of languages and tools that allow a rigorous specification of interfaces (at various levels of scale, including the subsystem level) is that such interfaces tend to focus one's attention on that which is essential at that particular level of detail. (This is nothing radical--it's the fundamental basis for abstraction...) -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *