Subject: Re: Why and how do organizations select the OO
Message-ID: <1993Jan22.144817.23862@mcc.com>
Sender: news@mcc.com
Reply-To: breland@cobweb.mcc.com
Organization: MCC
References: <1jo805INNfe@emx.cc.utexas.edu>
Date: Fri, 22 Jan 1993 14:48:17 GMT
Lines: 86
In article 1jo805INNfe@emx.cc.utexas.edu, kalakota@emx.cc.utexas.edu (Ravi Kalakota) 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 Design"?
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 builds
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 throughout
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 regarding
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 software development methodologies. In other words, Joe Schmo at Foo Aerospace may have 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 encapsulation.
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
