From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.8 required=3.0 tests=BAYES_50,FROM_ADDR_WS autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 22 Jan 93 14:48:17 GMT From: swrinde!news.dell.com!milano!cobweb.mcc.com!breland@gatech.edu (Mark A. Breland) Subject: Re: Why and how do organizations select the OO Message-ID: <1993Jan22.144817.23862@mcc.com> List-Id: In article 1jo805INNfe@emx.cc.utexas.edu, kalakota@emx.cc.utexas.edu (Ravi Kala kota) writes: > > Why and how do organizations select the OO approach to Software Eng. Goodness, what an entre for another potential free for all... ;) >... There is an amazing >lack of objective, evaluative literature on the selection of methodologies >in software engineering. We seem to be carried away by the bandwagon effect >and are not spending enough time understanding the pluses and minuses of >new methodologies, their effectiveness in various types of application >development areas and their effect on people. I may sound pessimistic but >it is definitely time that we understood what external factors impact the >selection of methodologies and what impact does the selection of a methodology >have on the effectiveness of the development group. While the technical side >has progressed and is progressing, the management side is limping along with >lame theorizing which almost always has no practical value. > >Most authors also seem to be consultants and each of them is pushing his or >her own methodology without any assessment of how or why it better than the >other available methodologies in the market. Most of these people seem to >be interested in making a quick buck before the "fad" loses its charm. These >people come across as snake oil salesman rather than objective people. May I suggest an in-depth perusal of Grady Booch's book, "Object Oriented Desig n"? While he definitely has his own method and symbology, he does attempt to point out critical points at which to be careful when making decisions. Chapter 2 especially highlights the pitfalls and benefits of applying OO techniques. Some quotes of interest: "There is no single programming style that is best for all applications." "Object-oriented design thus represents an evolutionary development, not a revolutionary one; it does not break with advances from the past, but build s upon proven ones." The latter quote greatly eased my initial dismay at a methodology touted in some camps as the mother of all methodologies. The techniques espoused within the object-oriented approach corresponded with techniques I have used throughou t my career, even though I was formally trained in top-down structured design. Thus, I felt OO was another version of ivory tower academicians dressing the emperor in new clothes. It was difficult not to say "Yeah, right..." and dismiss their concepts from further consideration. After further deliberation, I agree totally with what Booch has to say regardin g the origins of OO. I think OO is a logical extension of the structured design dogma. As a logical extension, its implementation should be expected to be independently discerned and employed by any number of competent software designer/architects with structured training. However, its formal definition required the consensus drawn from those professionals seriously studying softwa re development methodologies. In other words, Joe Schmo at Foo Aerospace may h ave been abstracting and encapsulating away for years, but didn't know it until he read Prof. Harumptyrump's paper defining the concepts of abstraction and encapsulati on. No offense intended, Prof. Harumptyrump. ;) >Milt Fulghun points out that at OOPSLA'92 that there was a noticeable hunger >for application and experience papers, panel sessions and workshops. How are >we satisfying this need? TRI-Ada '92 devoted a tutorial, several panels, and a paper session to the application of OO methods to Ada development. Those papers reporting on actual experience re-emphasized the fact that no particular method fills all the gaps for all projects. Rather, each project employed differing mixtures of methods, symbologies, and tools. Their reasons for selection of each ranged from political to financial to technical to educational and even to psychological (where the best snake oil salesman won ;) ). >The best people for the kind of research which bridges the managerial aspects >with the technical are the people on the "western front", managers. Ahhhhh, no I tend to disagree here. The best people are the technical leaders who have the misfortune of translating desires/problems/results to/from the managers and the programmer troops. In conclusion, I must add that OO in the hands of the uneducated can be a dangerous thing. It is not to be dictated just because "OO is the currently accepted methodology, so do it." Instead, it must be applied judiciously and in concert with other approaches suitable to the application domain. Don't forget the domain encompasses project programmatics, as well as the technology itself. --- Mark A. Breland - Microelectronics and Computer Technology Corporation (MCC) Ada Fault Tolerance | voice: (512) 338-3509 3500 West Balcones Center Drive | FAX: (512) 338-3900 Austin, Texas 78759-6509 USA | internet: breland@mcc.com