Re: What is wrong with OO ?

[rmartin@oma.com (Robert C. Martin)]

In article <32B758D7.61EF@deep.net>, tansel@deep.net wrote:
> 
> a) Software industry is in a crisis. 
> b) The application gap is still growing
> c) Every year abandoned software costs the world economy unmentionable
> billions of dollars.
> d) Even many so called successful projects Today are big money drains
> e) The approach we use for systems development influence a, b, c and d
> 
> How can we justify massive collapses of big systems with hundreds of
> millions of dollars down the drain with a cool face? If we don't call
> this a failure, what are we going to call? If it not waste, I would like
> to learn your definition of waste. And, dangerous, yes, because it
> creates a false sense of security once people get used to it.

The logical leap that you are making is that "procedural programming" is
responsible for points a-e.  I'd like to see some concrete evidence to
that effect.  The other logical leap you are implying is that OO corrects
points a-e.  Again, I'd like to see some empirical evidence.

Now, my belief is, (and my own experiences bear this out) that proper
(repeat *proper*) use of OO techniques can help to make large software
projects somewhat more maintainable, more flexible, more robust, and more 
reusable. (Did I get all the buzz words in there?)  Not that they didn't
have some of those traits before; its just that OO can enhance those
particular traits by some amount.  And it seems reasonable (although I
have only the most miniscule amount of real empirical evidence to 
support this) that enhancing these traits has an impact upon your points
a-e above.  But I have no proof as yet.  And, as far as I know, neither
does the industry at large.

On the other hand, there are costs associated with OO.  Done properly,
the structural complexity of applications increases, sometimes dramatically.
This complexity is what enhances the maintainability, flexibility, etc.  But
the cost is real.  I have experienced the payback.  I know that OO is
almost always worth the cost.  Indeed, when a large supply of reusable
components is assembled into a framework, the savings can be significant.
But the cost must still be paid.  (See my paper "ETS Case Study" available
from the freeware section of my website).

Another point is that there is massive confusion in the industry regarding
methodology.  Should you use Booch?  OMT?  UML? How about Shlaer/Mellor?  Some
of these methods are remarkably different from the others.  Which one yeilds
the best benefits.  IMHO, some of them work quite well, and some are 
exceedingly dangerous.  But who do you believe?

Thus, for the typical software manager, the costs of OO may overwhelm the
potential benefits.  If he makes the wrong choices with respect to methodology,
if he fails to adequately train his people in the proper use of OO, if he
expects to immediately reduce his costs, then for him OO will be more wasteful
and dangerous than procedural.

The manager who is careful to research the methods, who checks as much
empirical data as possible, who carefully runs trials without committing
his whole organization, who energetically trains his people, who makes
sure they are properly mentored during their first few projects; this manager
may reap the benefits of OO by producing systems that are easier to change, 
easier to maintain, and easier to reuse.  This manager may be able to build
up a stockpile of reusable software and arrange it in a framework that allows
applications to be developed in significantly less time than before.  But those
are very big IFs.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan