Path: utzoo!attcan!uunet!fernwood!portal!cup.portal.com!cliffhanger From: cliffhanger@cup.portal.com (Cliff C Heyer) Newsgroups: comp.software-eng Subject: Re: recap so far Message-ID: <31558@cup.portal.com> Date: 9 Jul 90 02:16:21 GMT References: <4235@<268462df> <39400111@m.cs.uiuc.edu> Organization: The Portal System (TM) Lines: 190 Cliff Heyer, the original poster, responds: The collection has diverged into sub-topics, the main one being a discussion of the merits of OOP and OOD. I FULLY AGREE that OOP has advantages, and will someday yield benefits beyond what can be had today. But the need to interface with billions of lines of old code and lack of standards will make this a slow and painful process. New stand-alone applications will be the ones to benefit. I began this collection to establish points of view regarding whether software be classified as engineering or manufacture (production, construction, assembly). I asserted that the nature of programming is inconsistent with the definition of "construction" and therefore use of the word with software is incorrect. My observation was that the industry should place emphasis on classifying software creation as engineering, and replicate the standards and procedures used by engineering departments/firms as pertaining to the making of estimates, rather than emulate the practices of the construction/manufacture industries. I asserted this would benefit software development by reducing programmer/manager burnout. I asserted this would benefit software development more than the adoption of various new metrics such as function point analysis, etc., which attempt to create an accurate measure of something that is not measurable in the first place. (Flame me if you want, I can back up my assertions.) I don't recall any firm arguments against these assertions, but please speak up if you are there. I request comments from persons with hardware engineering estimation experience for comparison to policies of the software industry. [Some of the following comments were lost to another collection, so I've encapsulated and summarized my points further below.] ========== It is not correct to say "with software you can separate the design from the construction phase." My point is that the "construction phase" is NOT really a construction phase based on the definition of construction. "Construction" is defined as "assembly." "Assembly" can only occur when someone has already created the parts and a plan to combine them (an engineer). With software no one has BOTH created the parts (functions) AND a plan to assemble them (loops, conditionals, etc.), so there IS NO ASSEMBLY and THEREFORE THERE IS NO CONSTRUCTION. This misconception causes managers to expect more accurate estimates than are possible, leading to manager/programmer burnout. With software you are NOT assembling components, you are DEVELOPING new components and a control structure to surround them. This is engineering. The terms ***** ARCHITECTURE and ENGINEERING ***** should be used instead of "design" and "construction" respectively. Software estimates should be made the same way hardware engineers make their estimates. Lets discuss hardware estimates. Do such estimates allot a fixed amount of time for each chip to estimate a board design? (eg. 80386 = 2 weeks, etc.) ========== Engineering deadlines are by default flexible. You can't market a TV that does not work, right? Therefore the deadline gets moved whether anyone likes it or not. And I see evidence that those engineers are not pressured to the same degree as programmers. Management knows that pressure = errors = delayed completion = increased costs. (But then you have to weed out loafers who take advantage of a non-production environment to not produce.) ========== It is NEVER right to design a software system ONLY on paper for the purpose of devising an estimate, unless you can be happy with an estimate that may be way off. Such estimates are bound to be useless because numerous coding difficulty assumptions will be wrong without support of actual time measurements. These errors propagate in an exponential manner throughout layers of code. The best that can be hoped for is a "estimate as you code" procedure where you use actual experience on the project to gauge the completion. From my experience, I can predict to the week the completion of certain projects after completing only 20% of the project. The paper estimates at the start NEVER correlate to the actual time. ========== John Dudeck writes.... >A lot of what is gained in OOD is in the de-sequentializing of our problems. How does de-sequentializing happen?? Not because of the "magic" of OOP. Old command line interfaces had HUGE amounts of code to tokenize strings and then conditionals to figure out the command before executing the appropriate subroutines. STATE TABLES and related code were huge. All OOP has done is remove this layer, by having the user do the "IF" and "TOKENIZE" by pointing to what he wants and clicking the mouse. In other words, instead of using the computer to figure out the command we let the user tell the computer the command by pointing to it and clicking. No magic here, just the expected result of a change in hardware/ software architecture. So I agree the de-sequentializing occurs, and this is one of the exciting things to me about OOP. But I can't give OOP the credit for it. It's a result of the MOUSE. ========== Perhaps component reuse is one place where the federal government CAN help. I'm thinking of how AM STEREO got messed up because the government didn't come in and standardize. Now we have three or so types of AM stereo and much more complicated decoder chips in the radios to detect and decode each kind. COLOR TV's introduction was smooth because of the decision to support one format. What if the FCC begins to regulate local area networks like they regulate the phone system, and proclaimed X-Windows to be the standard? Perhaps we could get on with life and do bigger and better things rather than waste man hours creating dozens of different GUIs? (eg. X, Windows, Presentation Manager, MacOS, etc.) ========== Because software only requires thought to create, often it takes LESS THOUGHT to MAKE a component yourself than to LEARN to re-use an existing one. This is a strong obstacle to component re-use. A managerial directive must be enforced, but this may conflict with "time to market". ========== We have to look at how people get satisfaction in their work. If a programmer gets satisfaction from "using his own code" then obviously he will always resist using components. The activities by which a person gets satisfaction can directly contradict the activities needed to produce acceptable work. (eg. drug addiction an extreme example). The need for a manager who is sensitive to and can interdict destructive satisfaction-getting cannot be overstressed. The same problem can occur with managers, for example, if a manager gets satisfaction from saying humiliating things to subordinates. ========== Edward J. Prochak writes.... >My bottomline point is that tuning > may not require change source code. >It may just as likely involve swapping >one object with a similar one having >different performance attributes that >better match the application. > >Does this sound close to being in the ballpark? YES! But this is a long ways off! I can't fathom the task of trying to standardize components, and then growing to a level of sophistication where we could choose different flavors of the same components. And doing all this trying to interface with billions of lines of code written the "old fashioned way." Clearly there is a route to the future here. But we are not there now, and these concepts don't solve today's problems. It is the job of the academicians to lead us to this "Garden of Eden" for future generations. ========== >Consider the lowly cash register. Most people (that can include us >software types) don't think much about such commodities,.... > Do we or the store owner or almost anyone else >care if the code inside is structured or spaghetti or in assembler or >COBOL (yes, there are cash registers running COBOL) as long as the right >barcode gives the right price and it doesn't bill the wrong amount to >our credit cards? This shows how UNimportant ELEGANCE of code can be! I'm not a proponent of elegant code. I'm a proponent of code that gives the user an adequate level of performance and functionality. This is why I think software paper designs can only be a small part of the design effort. You can only *with accuracy and certainty* establish performance and functionality"by using the ACTUAL PRODUCT, not a paper design. You can't gauge the speed and "feel" - that will give you competitive advantage - until you've completed a portion of your product. THEN you'll know if your design is worth a hill of beans or not. I am angered by people who confuse "excessive elegance" with "acceptable performance and functionality." CORRECTNESS cannot be compromised! Cliff Heyer