Am trying to quantify the benefits of OO

Am trying to quantify the benefits of OO

Post by Ruslan Shevchenk » Sat, 07 Jul 2001 04:05:04






>>All,

>>I'm looking for [reasonably rigorous] business case studies that quantify
>>the efficiencies to be gained after incorporating OO design methodologies
>>or common object model.

>There are no such studies because there are no such efficiencies.

This remind me old folklor story of 70-th:

 When interactive mode of computers become aviable:
// i. e. programmers can receive output of program immediatly, after
// entering it in computers from keyboard, not after few hours
//after putting perfocards inside, as in packet mode
 one solid organization decide to research benefits of interactive
mode: 2 groups of programmers was selected, test tasks, with few
repetitions.

Result of research was next:
  "Difference in programmer productivity when using interactive mode
   and packet mode IS NOT EXIXTS". I. e. productivity depend in most
   from level of qualificaton, not form mode using.

P.S.  To be not offtopic of CORBA newsgroup: reusing really exists
and it save some cost. From other side, silver bullet really not exists.

Quote:>    --bks

Ruslan Shevchenko
GradSoft: Chief Software Architector
http://www.gradsoft.com.ua/eng/
------------------------------------------------------------
Posted via http://MailAndNews.com
------------------------------------------------------------
 
 
 

Am trying to quantify the benefits of OO

Post by William Pietr » Sat, 07 Jul 2001 13:55:43



> I'm looking for [reasonably rigorous] business case studies that quantify
> the efficiencies to be gained after incorporating OO design methodologies
> into an existing software engineering process

I've been doing OO design and development off and on for a decade or so,
and I'm very pleased with the results. The larger a project, the more
likely I am to use OO.

But when you talk about incorporating it into an existing software
engineering process, that makes me a little nervous. In my experience it
takes developers quite a while (say 6 months to 3 years) to get the hang of
OO analysis and design; during this period they can be dangerous to
themselves and others.

Rummaging through McConnell's "Rapid Development," I find some backup for
that. Under section 15.5, he talks about some things that are often thought
of as silver bullets, including OOP:

    Object-oriented programming is delivering major benefits in the area
    of reusability, but the promised benefits in the areas of naturalness
    and ease of use have been disproved (Schlotz, et al. 1994). Object-
    oriented programming integrates many of the best ideas of the last 35
    years of software development, but learning to use it well is
    difficult. It places more of a burden on the developer rather than
    less, and it should be viewed as an expert's technology. When
    viewed that way, it is a valuable addition to the developer's toolbox.

In Chapter 19, "Designing for Change", he talks more about OO:

    The practice of hiding changeable design decisions inside their own
    modules is known as "information hiding," which is one of the few
    theoretical techniques that has proven its usefulness in practice
    (Bohem 1987a).[...] large programs that use information hiding have
    been found to be easier to modify--by a factor of four--than programs
    that don't (Korson and Vaishnavi 1986). [...] In structured design,
    the notion of black boxes comes from information hiding. In object-
    oriented design, information hiding gives rise to the notions of
    encapsulation and visibility. [...]

    A study at NASA's Software Engineering Laboratory found that object-
    oriented development practices increased reusability, reconfigur-
    ability, and productivity and they reduced development schedules
    (Schlotz, et al. 1994). [...] Use object-oriented design, but don't
    expect it to be a cure-all. [...]

And these are the relevant excerpts from his bibliography:

    Schlots, et al. 1994. "Object-Oriented Programming: the Promise and
    the Reality." Software Practitioner, January: 1,4-7.

    Bohem, Barry W. 1987a. "Improving Software Productivity." IEEE
    Computer, September: 43-57.

    Korson and Vaishnavi. 1986. "An Empirical Study of Modularity on
    Program Modifiability." In Soloway and Iyengar 1986: 168-186.

I broadly agree with this, although I feel that two more recent notions,
those of design patterns (see the book from Gamma, et al) and refactoring
(see Fowler's book by the same name) , have made it so that non-experts who
practice these techniques have an easier time getting started and a harder
time painting themselves into corners. But it's still no silver bullet.

Another paper you may find useful is found here:

    http://www.elj.com/eiffel/projects/bytex/

It describes a company's experience adopting object-oriented technology for
a major project and the many good and bad things that happened to them. I
recommend this highly.

If you want to contact me directly for more information, feel free to drop
me a line.

Regards,

William

--
http://scissor.com/

 
 
 

Am trying to quantify the benefits of OO

Post by Graham Perkin » Sat, 07 Jul 2001 21:41:23




> >I'm looking for [reasonably rigorous] business case studies that quantify
> >the efficiencies to be gained after incorporating OO design methodologies
> >or common object model.

> There are no such studies because there are no such efficiencies.

Many journals and magazines contain many reports of companies'
experiences with introducing various technologies, paradigms,
and practices.

But it should be obvious that to "quantify the efficiencies to be gained
after incorporating XXX" would be pretty hard, if not impossible,
whatever
the XXX was you were talking about.  Do you think any businesses can
afford to mirror themselves, then run one version under old system and
another under new?  Is there any sense in focusing on a design
methodology for your software as a central point in your efficiency?
What about the way you procure and accept software systems?

One eiffel developer reported that software maintenance requests
got serviced in days instead of weeks, after the re-designed some
comms. software with OO and eiffel.  But maybe that was the quality
of the developers?  

Our admin. systems at this University are absolutely dreadful.
They create huge amounts of work and never produce timely or
accurate information.  It's got to the stage where our admin staff
are not allowed to run queries or get reports.  They have to email
the query details to IT bigwigs 50 miles away, who run the query
next morning, and then send back printout by courier.  Luckily in
most cases we had the sense to continue running paper systems in
parallel, so can use them.  The IT system just sucks a few million
pounds out of our budgets and makes us work twice as hard to
get half the support.  It's all procedural/relational, so do we
blame the paradigm?

Of course not.  The entire systems management and software
procurement process is at fault.  

--
http://www.mk.dmu.ac.uk/~gperkins/

 
 
 

Am trying to quantify the benefits of OO

Post by Graham Perkin » Sat, 07 Jul 2001 22:25:13


Quote:> Every major OO project in bio-informatics for the last 10 years
> has crashed and burned.  

I suspect you will find that is true of many areas and many
paradigms.  A "major OO project in bio-informatics" has a number
of problems to cope with

- It's major.  Humans have not yet found out how to make
  major projects at all successful, except in a few exceptional
  cases

- It's OO, which is to say, committed to a paradigm for its
  own sake rather than for its benefits in that particular area

- It's OO, which means the developers have a number of tools and
  features at their disposal to help with good software engineering.
  Sadly, few large teams consist of a majority of good software
  engineers.  If you want a bunch of amateurs to build you a boat,
  give them saws and hammers, not robot machine tools.

- It's OO, which is a bit of a bandwagon jumped upon by many
  people who can tweak a GUI tool but wouldn't have a clue about
  properly structured object systems, or modular/relational systems
  either for that matter.

- It's bio-informatics.  The developers and people they talk to
  might be software whizzes with poor specialist bio knowledge,
  or bio-wizzards with poor software understanding

Now it's obvious to me why quantifying benefits of a given paradigm
is difficult in such large and complex context, but I'm sure plenty
of people have examined reasons for failure.  It's a fertile area,
I believe.  So, perhaps you ought to look up the previous projects
and review their reasons for failure.

After all, if main reason is not paying enough to get decent
analysts, then you can structure your C and Fortran all you like
but won't improve the situation!

OTOH if complexity of C++ was a major factor, then look to
switch to other languages.

Quote:> We are still using the tools developed
> in Fortran and C in the last generation.

I am familiar with some such tools in other technical environments.
They are not without their faults.  I know of certain fortran
programs in chemistry which "process" the results of other fortran
programs in order to make the physical readings closer to the
theoretically predicted values.  As Dijkstra said, scientists
no longer replicate each others' work, they simply copy each
others' Forgran bugs.  Another such tool I know of is implicated
in a tragic accident leading to several deaths.

Quote:> The Internet owes nothing to OO.  

There are many common aspects to both.  Both have grown out
of the same milieu.  Surely you can see the connection between
client-supplier systems, multi-tiered architecture, and OO?
Java, XML, and Component technologies are all important parts of
the internet today.

Quote:> Like structured programming, OO promises the
> world and delivers nothing new.  

Well, if you must read the marketing brochures ;-)

IMHO both make moderate promises and deliver.
Can you imagine the problem we'd have now maintaining legacy
software if nobody had structured it around statement,
procedure, and module level single-entry-single-exit constructs?

Quote:> The need for careful analysis and implementation continues.

Of course.  And failure to observe this screws up any approach.
But OO is not about skimping on analysis, imp., or any other
area of software engineering.

Quote:> For all the hoopla there should be quantifiable improvements
> due to OO.   There are none.

You want a print out of my GUI kit written in OO and similar
attempt I made with modular programming?  Looks and feels
pretty quantifiable to me.  You want to compare size and
maintainability of object-based MVC interactive systems with
modular event-handler systems?  Plenty examples abound.  You
find a delphi program and I'l find a smalltalk one to do
similar task.  Then we can start counting LOC or timing work
required to handle a change in spec.

Quote:> Instead the OO proponents continue
> to have empty arguments about how many circular objects can
> dance on the head of an  elliptical pin.

Not me, thanks.

Quote:> At least in the
> structured programming age we actually solved problems.

I thought you said structured programming promised everything
and delivered nothing?

Quote:> The world is *not* composed of classes of things.  

Agreed 100%, and "OO models the real world" is one of the biggest
pieces of misdirected ill-informed propaganda out there.  

However, nor is the world made of modules or tables or single
entry single exit control structures or Venetian double-entry
account books or quipu knots.

What is interesting is how to model the information and
processes we need to help us handle complex activities in the
real world?

Quote:> The world
> is a biofilm that can think and move.  In a biofilm, you cannot
> draw lines where one entity ends and another begins.

True, but not relevant.  We're dealing with information and
processes.  Notions of entities and boundaries are different
in such a world.  For example, the distinction between a
credit-transaction and a debit-transaction is a lot clearer
than that between a tree and a bush. (OTOH there are other
kinds of boundaries which are more fuzzy or dynamic, and we
have to handle them in non-real-world-like ways)

--
http://www.mk.dmu.ac.uk/~gperkins/

 
 
 

Am trying to quantify the benefits of OO

Post by Warren R. Zeigler S » Sat, 07 Jul 2001 23:32:13


Oh Gee - That's why everyone codes to Windows using the API without
encapsulating it within an object foundation class! I always wondered...

--
Warren R. Zeigler Sr
http://www.UnderstandingObjects.com





> >All,

> >I'm looking for [reasonably rigorous] business case studies that quantify
> >the efficiencies to be gained after incorporating OO design methodologies
> >or common object model.

> There are no such studies because there are no such efficiencies.

>     --bks

 
 
 

Am trying to quantify the benefits of OO

Post by Attila Fehe » Sat, 07 Jul 2001 23:41:09


This is an automated response to a post you have tried to address to
Attila Feher.

You have been killfiled, with the reason(s): troll, flame.

Don't bother addressing me in your posts, I don't see them.

This mail is sent only one time, just to ensure you don't waste more
electrons and time.

Have a nice day.

KFSC0.3.341

 
 
 

Am trying to quantify the benefits of OO

Post by Topmi » Sun, 08 Jul 2001 01:58:12


Quote:> This is an automated response to a post you have tried to address to
> Attila Feher.

> You have been killfiled, with the reason(s): troll, flame.

> Don't bother addressing me in your posts, I don't see them.

> This mail is sent only one time, just to ensure you don't waste more
> electrons and time.

> Have a nice day.

> KFSC0.3.341

Think I care? You never argue technical issues
nor show code anyhow.

BTW, here is a test of your killfile:

Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!
Attila The None is a proofless jerk!

If the test is successful, you will never
see this.

-T-