Re: Why and how do organizations select the OO

Re: Why and how do organizations select the OO

[swrinde!news.dell.com!milano!cobweb.mcc.com!breland]

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

Re: Why and how do organizations select the OO

[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."
------------------------------------------------------------------------

Re: Why and how do organizations select the OO

[Bjarne Stroustrup]

mfeldman@seas.gwu.edu (Michael Feldman @ George Washington University) writes

    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. 

I realize you probably can't name names, but it would be nice if you could
for two reasons. Firstly because charaltans ought to be exposed, secondly
because someone could misinterpret your statement into something condemning
lange groups of ``OO-experts'' as windbags who don't deliver. (there are
no shortage of windbags and self-proclaimed ``experts,'' but no one field
has a monopoly on them).

Re: Why and how do organizations select the OO

[Bob Kitzberger]

bs@alice.att.com (Bjarne Stroustrup) writes:

>mfeldman@seas.gwu.edu (Michael Feldman @ George Washington University) writes
>
>    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. 
>
>I realize you probably can't name names, but it would be nice if you could
>for two reasons. Firstly because charaltans ought to be exposed, secondly
>because someone could misinterpret your statement into something condemning
>lange groups of ``OO-experts'' as windbags who don't deliver. (there are
>no shortage of windbags and self-proclaimed ``experts,'' but no one field
>has a monopoly on them).

There is a possibility, of course, that the design was indeed 'good', but
the engineers on the project weren't qualified enough (read: OO-educated,
open-minded, etc.) to implement it.

	.Bob.
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888

Re: Why and how do organizations select the OO

[Michael Feldman]

In article <24691@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>
>I realize you probably can't name names, but it would be nice if you could
>for two reasons. Firstly because charaltans ought to be exposed, secondly
>because someone could misinterpret your statement into something condemning
>lange groups of ``OO-experts'' as windbags who don't deliver. (there are
>no shortage of windbags and self-proclaimed ``experts,'' but no one field
>has a monopoly on them).

You're right, Bjarne - I can't name names. I won't tar an individual with
an ad hominem public attack, especially if I have no independent basis for
it. I did not observe this consultant in action, nor see his work in this
case. His client was frustrated but I can't really assess the reason for
the frustration. And naturally no field has a monopoly on windbags.

As is often my style, I chose a couple of anecdotes to comment on a  
more general situation, and to provoke reactions like yours :-)

The point was not to tar OO experts as windbags, but to comment on the
state of things. The customer in this case is thrashing around, has
little knowledge of what's happening in the field, and is making purely
political/religious statements. My distress came from the fact that
the organization didn't seem really interested in finding out more
or get really educated. They were - as is so often the case -  arguing
from nontechnical starting points. There are pro-OO and anti-OO factions
in the group, neither being especially scientific. There is also a 
faction that believes the Ada mandate should be followed in their case,
and a faction that is working harder to evade the mandate that they
would need to work to follow it.

Their state of knowledge of OO truly seemed to be "It's that stuff that
C++ has and Ada doesn't." Some in the group were quite surprised to
discover (from me) that Ada supports information hiding and private types.
Their eyes glazed over when I got to the intricacies of inheritance.
Somebody told them that OO was the way to go, but apparently did not
explain just what that was supposed to mean. Somebody else told them
that Ada absolutely, positively, could not be used for what they had
in mind. They couldn't explain why, either, just that they'd read it
somewhere (Government Computer News, maybe?).

I wouldn't be surprised if there were more such groups out there.
Your tax money at work, folks.

Mike Feldman

Re: Why and how do organizations select the OO

[Bjarne Stroustrup]

mfeldman@seas.gwu.edu (Michael Feldman @ George Washington University) writes

 > The point was not to tar OO experts as windbags,

I didn't think you were, though of course SOME are.

 > but to comment on the
 > state of things. The customer in this case is thrashing around, has
 > little knowledge of what's happening in the field, and is making purely
 > political/religious statements. My distress came from the fact that
 > the organization didn't seem really interested in finding out more
 > or get really educated.

and that's the real rub. Many organizations and people are so busy
``getting the job done'' or jumping on some bandwagon that they don't
want to take the time to learn anything new.

The real power of languages that support techniques beyond what is
directly supported by C/Pascal is exactly those techniques.

Ada supports data abstraction and C++ data abstraction and object-oriented
programming (let's quibble about the meaning of those words elsewhere
if we must; their exact meaning isn't important to what I'm trying
to say here) and unless you take the bother learning those techniques
you are not going to get anywhere near the benefits from Ada/C++ that
you might.

One way of expressing this is that companies (and individuals) wants mere
training (i.e. ways of using new tools without absorbing new concepts).
What they need is education (i.e. new concepts and their related techniques).
Ada without some understanding of data abstraction, etc. seems to me to
be very nearly just Pascal, and C++ without some understanding of data
abstraction, etc. is just C with better type checking.

I don't know about the Ada world, but in the C++ world we do have a problem
with teachers and textbook writers who miss the connection between concepts
and programming language constructs and thus miss the point and makes learning
unnecessarily difficult for the students.

 > They were - as is so often the case -  arguing
 > from nontechnical starting points. There are pro-OO and anti-OO factions
 > in the group, neither being especially scientific. There is also a 
 > faction that believes the Ada mandate should be followed in their case,
 > and a faction that is working harder to evade the mandate that they
 > would need to work to follow it.

 > Their state of knowledge of OO truly seemed to be "It's that stuff that
 > C++ has and Ada doesn't." Some in the group were quite surprised to
 > discover (from me) that Ada supports information hiding and private types.
 > Their eyes glazed over when I got to the intricacies of inheritance.

Maybe you focussed too much on the intricacies and too little on the
concepts :-) I don't experience serious problems getting the object-
oriented concepts and the C++ language mechanisms that support then
across - the problem comes when the ideas have to be applied to real
projects (exactly, as for the data abstraction concepts and the language
constructs that support them).

Re: Why and how do organizations select the OO

[Harry Koehnemann]

In article <1993Jan22.203706.29355@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>
>    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.

Interesting.  I saw the same thing out here.  A friend of mine works at
a company (also nameless) developing a very large real-time system.  There
were many variables in this project  - new processor, new language (Ada),
very large project, drastically reduced cycle time, and new development
method (OO) - ie. lots of risk.  They had hired a consultant to help in
specification and design who basically told them that "if you're going to
use Ada, you have to use OO spec/design"  Hmmm.  Does Ada preclude other
design methods?  You can't get encapsulation/info hiding from other
methodologies?

Of course, everyone followed the consultant.  Not because he was right
(although he may have been), but because I'm sure no one in a decision
making power really knew any better.  As you say it's kindof like
religion - like the congregation following the preacher and assuming
it's his responsibility to get them to heaven.

BTW, last I heard it's behind schedule and way over budget - imagine that.
Too many variables for onw project.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

Re: Why and how do organizations select the OO

[Victor Giddings]

> In article 1jo805INNfe@emx.cc.utexas.edu, kalakota@emx.cc.utexas.edu (Ravi Ka
lakota) writes:
>
>	Why and how do organizations select the OO approach to Software Eng.
> 
>... There is an amazing lack of objective, evaluative literature 

Before this goes too far ...

No one PROVED that a word processor is "better" than a typewriter (in fact
some studies suggested that they are equally productive and that quality
remained a subjective matter).  That does not, however, give me ammunition
to take away my secretary's word processor (let alone the courage).  And
there is little debate in industry any more.

>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.    


Ultimately, we will probably have to depend on the informed opinion of
experienced practicioners.  Real projects have too many variables to serve
as controlled experiments, even if someone were willing to fund parallel
developments.  


> [much deleted]

Re: Why and how do organizations select the OO

[Michael Feldman]

In article <1993Jan25.155937.10417@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.
edu (Harry Koehnemann) writes:
>
>Interesting.  I saw the same thing out here.  A friend of mine works at
>a company (also nameless) developing a very large real-time system.  There
>were many variables in this project  - new processor, new language (Ada),
>very large project, drastically reduced cycle time, and new development
>method (OO) - ie. lots of risk.  They had hired a consultant to help in
>specification and design who basically told them that "if you're going to
>use Ada, you have to use OO spec/design"  

This is fascinating, Harry. The received wisdom I seem to be hearing a
lot of seems to use the same words to make a different statement: "If
you're going to use OO spec/design, forget about Ada, because it doesn't
support multiple inheritance." Both statements are BS, of course.
>
>Of course, everyone followed the consultant.  Not because he was right
>(although he may have been), but because I'm sure no one in a decision
>making power really knew any better.  As you say it's kindof like
>religion - like the congregation following the preacher and assuming
>it's his responsibility to get them to heaven.

Amen to that, brother! It has always been thus, though. My sense of deja vu
gets exercised more and more these days. I lived through the 70's, and taught
through the latter half thereof. "Structured programming" was the subject
of a similar religious crusade. "No GOTO's!" "GOTO's!" "Lots of procedures!"
"Procedures are inefficient!" Etc., etc. Eventually our views matured
and the languages and hardware caught up. 

Managers are, by definition, less recently educated than worker-bees, and 
have more at stake, so they seem to be eternally vulnerable to consultants 
and other crusaders. This is not to trash managers - it's in the nature of 
things, I'm afraid. One does wish for a modicum of intellectual honesty,
though. Sigh...
>
>BTW, last I heard it's behind schedule and way over budget - imagine that.

Surprise.

>Too many variables for onw project.

Ah, now maybe we're getting down to the point.

Mike Feldman

Re: Why and how do organizations select the OO

[Michael Feldman]

In article <24696@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>
[lots of good stuff deleted]

>One way of expressing this is that companies (and individuals) wants mere
>training (i.e. ways of using new tools without absorbing new concepts).
>What they need is education (i.e. new concepts and their related techniques).

Indeed. I am aware of a certain SE educator in the Ada world whose business
card used to say "education manager." His customer base grew a good bit
when he changed the title to "training manager." His customers didn't
want "education." Too "academic", they said. Turns out he taught the same
stuff, but they were willing to swallow it when he called it training.
Sigh...No wonder we're losin' it to the Japanese...

>Ada without some understanding of data abstraction, etc. seems to me to
>be very nearly just Pascal, and C++ without some understanding of data
>abstraction, etc. is just C with better type checking.

Indeed.
>
>I don't know about the Ada world, but in the C++ world we do have a problem
>with teachers and textbook writers who miss the connection between concepts
>and programming language constructs and thus miss the point and makes learning
>unnecessarily difficult for the students.

Well, I can speak as a teacher of neophytes, who have _tremendous_
difficulty making the distinction. They identify the concept with the feature.
I'm a pretty decent teacher, and working pretty hard at the distinction
between, say, data abstraction and packages. Indeed, I was teaching DA
several years before Ada even existed, in a data structures course.
The course is _still_ data structures, and Ada is used as the language.
Five years later, I'll run into students who say "Hi Mike. Remember me? 
I was your student in that Ada course." Makes me wanna scream.

I am convinced that the only way to show people how to distinguish concept
from language construct is to teach them _more than one language_, so that
they can see for themselves what is universal and what is language-dependent.
Alas, that is rarely possible in today's world, especially in industry.
It's even hard in college courses (except comparative languages courses)
to do two languages side-by-side.

At the University of Washington last year I taught a freshman course
whose requirements were 8 weeks of Ada followed by 2 weeks of Fortran.
I was _very_ gratified at the way the students reacted to the 2-language
model. Far from resisting it, they were fascinated by the similarities
and differences. And I daresay they learned more about fundamentals
by doing two languages than by doing one. Examples on request.

It's very difficult to compare an apple.
>
> > Their state of knowledge of OO truly seemed to be "It's that stuff that
> > C++ has and Ada doesn't." Some in the group were quite surprised to
> > discover (from me) that Ada supports information hiding and private types.
> > Their eyes glazed over when I got to the intricacies of inheritance.
>
>Maybe you focussed too much on the intricacies and too little on the
>concepts :-) I don't experience serious problems getting the object-
>oriented concepts and the C++ language mechanisms that support then
>across - the problem comes when the ideas have to be applied to real
>projects (exactly, as for the data abstraction concepts and the language
>constructs that support them).

I misspoke. I had about half an hour to give the "Ada viewpoint." 
Obviously there weren't too many intricacies discussed. The point was
that I believed that for their situation, Ada's weak single inheritance
could well be quite sufficient,so they could relax and stop fighting
the mandate.

DoD Ada implementation policies presume Ada's cost-effectiveness unless 
shown otherwise. I feel no need to trash C++ in order to show that Ada 
is viable, because that is all I have to show. I have no need to engage 
in a "my language is better than yours" crusade; I need only to show that 
my language will solve your problem in a cost-effective manner.

I'm tired of pi**ing contests...

Mike Feldman

Re: Why and how do organizations select the OO

[Pat Rogers]

In article <24696@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>
[lots of good stuff deleted]
>
>One way of expressing this is that companies (and individuals) wants mere
>training (i.e. ways of using new tools without absorbing new concepts).
>What they need is education (i.e. new concepts and their related techniques).
>

I have found this very much true.  Once when asked the difference, a wise
man said:

	"Sex EDUCATION is what you want for your sixteen year old daughter.
	TRAINING is what _you_ want."

p rogers
progers@ajpo.sei.cmu.edu

Re: Why and how do organizations select the OO

[agate!doc.ic.ac.uk!uknet!yorkohm!minster!mjl-b]

In article <1993Jan26.153250.18892@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes
>In article <1993Jan25.155937.10417@ennews.eas.asu.edu> koehnema@enuxha.eas.asu
.edu (Harry Koehnemann) writes:
>>Interesting.  I saw the same thing out here.  A friend of mine works at
>>a company (also nameless) developing a very large real-time system.  There
>>were many variables in this project  - new processor, new language (Ada),
>>very large project, drastically reduced cycle time, and new development
>>method (OO) - ie. lots of risk.  They had hired a consultant to help in
>>specification and design who basically told them that "if you're going to
>>use Ada, you have to use OO spec/design"  
>
>This is fascinating, Harry. The received wisdom I seem to be hearing a
>lot of seems to use the same words to make a different statement: "If
>you're going to use OO spec/design, forget about Ada, because it doesn't
>support multiple inheritance." Both statements are BS, of course.

I went for a job interview last week. Over lunch, I was talking to a guy
from the Air Traffic Control sector of the company I was being interviewed
by. We got to discussing Ada, and he said he knew very little about it, save
that it had concurrency features, and didn't support full OO inheritance.

Me:  "No, Ada 83 doesn't have full inheritance, but you don't need it for OO
design"
Him: "But inheritance is the cornerstone of OO design."
Me:  "Er... no it isn't"

Diplomacy (all right, the fact that I wanted a job) won the day at this point.
This is what people who have been designing and writing software for years
think... no wonder Ada has acceptance trouble.

>Mike Feldman

Regards,

Mat

| Mathew Lodge                      | "But my Lord! I've been in your family |
| mjl-b@minster.york.ac.uk          | since 1532!"    "So has syphilis"      |
| Langwith College, Uni of York, UK |  -- Blackadder II                      |