Re: Why and how do organizations select the OO

[seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman)]

In article <1993Jan22.144817.23862@mcc.com> breland@cobweb.mcc.com writes:
>
>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.
>
Two anecdotes about the faddishness of OO at the moment. 

(1) I was approached by a graduate student who wanted to write a
    masters thesis. I should add that this student works for a very 
    large government contractor on a very large project, an Ada one
    as it happens (not that it matters!).

    The student had a proposal in hand: "prove that OO is less efficient".
    The following (abridged) dialog ensued:

    MBF:     Less efficient than what?
    Student: Than traditional methodologies
    MBF:     Less efficient in what sense?
    Student: Slower and bigger executables
    MBF:     You think you can prove that?
    Student: Well, that's what the folks at work say
    MBF:     But how do _they_ know? Have they tried comparing apples
             to apples?
    Student: I don't know, but I don't think so. They are interested in
             seeing my results.
    MBF:     How about if we re-write your proposal so that you are
             _investigating_, for some appropriately boiled-down piece
             of your project, the run-time behavior of that program
             developed in OO fashion but also by a traditional methodology?
    Student: Oh, you want me to do the thing in two different ways, then
             compare?
    MBF:     Yup.
    Student: Hmmm....that's a good idea.
    MBF:     Yup. You might even be surprised by the outcome.

    The second draft is a bit closer to an honest assessment. 

(2) I had occasion recently to visit some folks in one of the military
    services, starting to develop a non-hard-realtime system. They are
    in a frenzy to sort out whether to use OO or not, and whether to
    use Ada or break their backs to get a waiver for C or C++.

    They hired a _really_ big-name consultant (NOT a professor, Mark!)
    to teach them his OO methodology and take a first crack at a design
    for them. After collecting a very large fee, he walked away from the
    project, leaving behind what they say is an unworkable design. 
    Conceivably we (I and another professor friend) will get involved 
    helping them sort it all out. Might be fun.

    In this group, the battle over both OO and Ada is purely religious.
    Seemed to me to be pretty devoid of technical content. And no, I
    won't tell you what group it was. I was there, though. And other 
    friends have told me that this is typical of the state of things 
    right now. OO is defined in these circles as "I don't know much
    about it, but it's that stuff that C++ does and Ada doesn't."
    And nobody can say for sure whether it will "work", whether it will
    improve cost-effectiveness, and by how much. Same old handwaving.

Just thought I'd jump in with my $0.02.

Mike Feldman

PS - Read J-P Rosen's paper in the November CACM.
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------