Re: What is wrong with OO ?

[nigel@access1.digex.net (Nigel Tzeng)]

In article <32B3F45C.5140@deep.net>, Tansel Ersavas  <tansel@deep.net> wrote:
>Robert C. Martin wrote:
>> 
>> In article <32AA207E.3199@deep.net>, tansel@deep.net wrote:
>> 
>> > There are three major reasons why OO projects fail. All of them are
>> > stated by the great wisdom of Jedi in "Star Wars".
>> >
>> > These are:
>> >     "Do or do not. There is no try"
>> >     Using my tools and techniques, I can prove you that I can produce
>> >     better and faster systems using OO (Please read my notes at the end
>> >     of this message). If I can do it, so you can.If you just try to do
>> >     it, you will fail. Be determined to do it.

Why does this remind me of the get rich on real estate seminars?  Well, gee
people fail using my strategy becuase they weren't committed enough.  They
didn't truly believe it would work so it failed....

[snip]
 
>First of all, my opinion is, developing systems with procedure oriented
>techniques is a dangerous, wasteful and unproductive process. So far OO

Any particular reason why?  Do you have metrics that show that procedure
oriented techniques are inherently dangerous or wasteful?  What do you
mean by dangerous anyway?

>couldn't show a quantum leap of difference, but it is not mature yet.
>When I train people, I look at their background. Usually the more
>experienced in the traditional techniques they are, the less they
>believe the necessity of learning a new technique. In my breakthrough

IMHO this is more likely the case of being around the block a couple
of times and seeing several "silver-bullet" approaches fail miserably
rather than some inherent dislike of doing something different.

We are an OO shop and there are many advantages to doing OO design but
is it the savior of all programming projects?  Nah.  Is it really THAT
much more efficient or successful than SASD?  Nah.

Why?  Becuase the root cause of a lot of project failure isn't with
the underlying technology (OO vs SASD) but due to the politics and
social dynamics of any project.

My opinion is that peopleware issues are more important than the
underlying methodology used in a project...and that you are far more
likely to see these "order of magnitude" productivity changes by
adhering to Peopleware than OO (not that Peopleware is a silver bullet
mind you :).

[procedural thinking vs OO deleted]

>Anybody wishing to see these techniques in action, I'm happy to
>demonstrate them. It is the only proof I can show to anyone that OO
>works, and works much better than anything they have seen so far. And
>without unlearning, it wouldn't have been possible. 

I think that most members of this newsgroup are open to new ideas and
success stories.  Feel free to share your experience.

[snip]

>I'll remind you of the placebo effect. IMO belief creates miracles. But
>it is also true that blind faith is dangerous.

Great...well I suppose that we can increase productivity by changing the 
light level every couple of months.

>Any time a new paradigm comes around there are pioneers. They make the
>bold decisions to shape the history. They are less than 1% of the
>participants. Pioneers are nothing but visioners and believers. They
>create their evidence, and history.

And never ever let one of these folks lead your project.  Yeah, they will
strike gold 1% of the time but do you really want to be on the other 99%
of the projects?

Now these folks can change the face of the market...but it's too bad
that in general some popularizer steals the market from the visionary.

Steve Jobs lives here...

>Then there come early adopters. People who don't need "empirical
>evidence". Who use their intuition to make sense of what the pioneers
>are pointing to.

These folks have a higher success rate but people who live on the cutting 
edge tend to bleed.  Will they really gain a significant market advantage?
Depends a little on luck...but if there's nothing to lose.

I'd say Netscape lives here...they scored big by early adoption of
internet technology and splitting off from NCSA.

>Then there are popularizers. People are quicker than the others, just
>like the people who watch the other traffic lights to see when they are
>going red so that they could be the first to respond to the green light.
>They require evidence, but can act very quickly. 

Probaby the best place to live...the visionaries and early adopters
has weeded out the "looked like a good idea on paper" strategies out
and there are valuable lessons to be mined from their successes and
failures.

Here be Microsoft...or maybe a little lower. Wherever they live they
seem to real good at stealing markets from visionaries and early
adopters :)

>Then there are followers, much like people passing at the green light.
>They do nothing but go with the crowd. There must be empirical evidence
>for them.

And most of us sit here.  After all, most of us aren't doing anything
to win Nobel prizes over or changing the face of the market.

[snip]

>In fact, I can't follow all of it, but during this discussion about
>what's wrong with OO I tried to observe any excitement, but couldn't see
>much of it around.

The thing is that the best programmers out there are constantly
learning, making improvements and adopting new technology as it
becomes useful.  But they don't tend to be zealots over any particular
tool or even set of tools...because one you buy into a particular
paradigm with heart and soul you're a lot less likely to change or to
see the problems with the paradigm.  

Besides...methodologies are only tools...important in that they help
us get the job done but they are not and should not be the focus of
our excitement (unless we are researchers).

There is an interesting comment I read in a home theater magazine
where an individual states that he never wanted to be one of those
people who said "Hey, you have to come over and see/hear my system!"
because the objective is to come over and see a movie or hear music.
The A/V equipment should be so good as to be unnoticable.

Likewise I'd rather say "Hey, come use my great new product" and not
"Hey, we designed this thing using OO isn't that great!"

>> Robert C. Martin    | Design Consulting   | Training courses offered:

>Tansel Ersavas

Nigel