From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: tbushell@fox.nstn.ns.ca (Tom Bushell) Subject: Re: What is wrong with OO ? Date: 1996/12/11 Message-ID: <32ae8fca.378135317@news.nstn.ca> X-Deja-AN: 203533133 references: <32A4659D.347A@shef.ac.uk> <32a5ceba.81462731@news.nstn.ca> <32a7ae3c.11882739@news.nstn.ca> organization: Telekinetics newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1996-12-11T00:00:00+00:00 List-Id: On 08 Dec 1996 18:44:08 +0000, piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote: >tbushell> I agree that the effort is useful. But my gut feeling is that >tbushell> with better (and apparently undiscovered, as yet) processes >tbushell> and tools, the high level design activity should be about 10% >tbushell> of the total project, not around 50%. > >Perhaps the reverse: if the tools were really advanced, perhaps >including a program generator (and despite claims to the contrary no >such thing has been yet produced), then high level design activity would >be almost all the project. Good point, although I suspect the bulk of the effort would be in what is currently called "detailed" design. This is what I would like to see happen. >However designing a bridge and building it are not a good analogy for >analysis/design and vs. coding; more like an analogy for all three of >analisys/design/coding vs. execution. I _think_ you are saying you believe _building_ a bridge is analogous _executing_ a program. If so, my reply would be that executing a program is more like opening a bridge to traffic - construction is complete and it has been turned over to it's intended users. >Well, my impression is exactly the opposite: that the design of material >entities like a new car or an airplane model requires immense amount of >money and time, as compared to almost any software project, and as many >iterations, and as much debugging, if not more, and then there are as >many *design* bugs (as opposed to manufacturing defects) in the finished >products. You may be right. I've never seen any statistics on how much of the new product development effort can be attributed to design, but I know it is significant. >tbushell> Also, the OO design models I've studied don't seem to be very >tbushell> good maps of actual real world systems - there seems to be a >tbushell> big gap between high level architecture and running code. I > >This is a good reason why architectures as maps of real world system are >not such a good idea. Interesting point. If you are saying that architecture/civil engineering are perhaps not the best fields to look to for inspiration, I'm starting to agree with you. Seems there may be more profit in looking to mechanical engineering and biology - both deal with much more dynamic real world objects. A software system is more like a machine or an organism than like a bridge. Thanks for that insight! > >tbushell> believe there should be a fairly smooth continuim from high >tbushell> level to low level of detail. The point I was trying to emphasize was my perception that there seems to be a big chasm between the high level design models currently advocated, and running code. Perhaps this is why "over the wall" processes fail - only the architect has enough understanding to make the leap, so he/she must also implement. This makes me suspect one or more of the following are true: 1. Current high level design models are inappropriate 2. Additional high level design models are required to supplement existing models 3. "Intermediate" design models are required to bridge the gap between high level and detailed design/coding. >I am asking for any argument to support the statements you make. You >support your observations with reference to "my gut feeling", "Or so I >believe", and "I believe there should be". Quite deliberate choice of words on my part. My intuitions are _usually_ correct, which has served me well in predicting technological trends. But I have only my limited experience to go on with modern design methodologies, and was trying to get some harder data, or at least anecdotal evidence to substantiate or refute my hunches. >tbushell> Absolutely! But why doesn't it work out that way? > >Because achieving this requires hard thinking. This is typically beyond >the state of the art. > >Or perhaps because the rather vague statements by those who believe in >``silver bullets'', in particular those with ``real world modeling'' on >them, mean that many people don't focus hard enough on the structure of >programs _as such_; there is evidence as to what is a good structure for >a model of the ``real world'', and then that this would also be a good >structure for a program. There is instead some sparse but good evidence >about what is a better structure for a program as such. Again, a good point. I read this to mean you might be in agreement with my point #2 above about current models being insufficient. Perhaps we should be using software patterns to constrain the allowable design models that can be produced, so they will be more likely to be implementable. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ----------------------------------------------------------