Re: The Failure of OOP
From: Alan Gauld (alan.gauld_at_btinternet.com)
Date: 04/09/04
- Next message: christopher diggins: "Re: The Failure of OOP"
- Previous message: Shayne Wissler: "Re: xp and simple design"
- In reply to: H. S. Lahman: "Re: The Failure of OOP"
- Next in thread: H. S. Lahman: "Re: The Failure of OOP"
- Reply: H. S. Lahman: "Re: The Failure of OOP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 08 Apr 2004 23:46:54 +0100
On Thu, 08 Apr 2004 16:08:40 GMT, "H. S. Lahman"
<h.lahman@verizon.net> wrote:
> >>Nobody ever promised simplicity of design or speed of <original>
> >>development.
> > Unfortunately they did. Several vendors ....
> > And many management types and not a few programmers believed
> > it...
> >
> >>programming. Nor did anyone promise that OO programs would execute
> >>faster or even as fast as procedural programs.
> >
> > ...excitedly published examples of C++ outperforming C programs
>
> Tool vendors tend to do that. Remember Expert Systems in the late '80s?
> But not a lot of theoreticians and methodologists ...
Indeed, and those of us in my own company who had OO
experience(*) were shouting from the rooftops that it wasn't so,
but the procurement and management guys were in hermetically
sealed rooms talking to the vendors, so they didn't hear us...
:-)
(*)I started with Smalltalk in 1984 and Lisp in 1988. Others had
used Simula and Objective C, and a few researchers had played
with Smalltalk. But the big push came in 1990 and the management
bought into C++ big style - then in 1998 we all jumped to Java
(well except for me, I moved to Python! But that's another story
:-)
I know of at least 1 department who by 1998 had dropped OOP as a
failure and retrenched to procedural techniques (COBOL and C)
after some collosal OO project failures (the classic OOP "it
takes two false starts before you get it" syndrome). Largely due
to unrealistic expectations set by vendor promises.
> On the MLOC application we needed a staff of eight people full time to
> deal with ongoing enhancements and bug fixes for the SA/SD/SP version.
> That went to one person part time for the OOA/D/P version.
That kind of fits our experience in that a 3.5MLOC C++/Lisp
application would normally have had 35 maintenance programmers
assigned (we used a standard metric of 1 per 100KLOC). It became
obvious after a few months that the OOP code only needed one per
500KLOC so we reduced to seven. After a year the team had gained
enough experience to drop it to 5.
But the bulk of the maintenance work was minor enhancements. Bug
fixing took about as long regardless of implementation technique
- with a 24 hour max turnaround allowed you had no choice!
What gave a lot of difficulty was the heavy use of MI in the Lisp
code - it was difficult to find where methods were defined with
several different trees to walk each one potentially
redefining/extending the virtual method. Our core object type was
an amalgam (by inheritance) of over 30 classes. This core object
was then subclassed into around 200 leaf nodes.
> FWIW, my personal experience is that fault diagnosis and repair is much
> faster. Roughly 70% of the time the fault can be diagnosed by
> inspection looking at the statecharts for just a few minutes.
Thats interesting, one of the lessons we learned was that state
charts (specifically SDL process diagrams) were very useful for
documenting object behaviour, with a message representing an
incoming event. Unfortunately that big project was not documented
using statecharts (there weren't many published OOD methods
around in 1990...)
> Once the fault is diagnosed I don't see any difference
> between enhancement and repair.
Agreed but diagnosis generally takes 75% of the time in bug
fixing. If the documentation is poor to non existent and you have
to rely on the debugger OO definitely slows things down.
(although modern debuggers are getting better at presenting
an OO view of the code)
> >>complicated, hard to read, and difficult to maintain, it is because they
> >>were not properly constructed using good OOA/D practices.
Or not documented...
> > And this is why the studies mentioned are ambivalent. Nobody
> > could agree about what constitutes well written/designed OOP.
> It's like Art so one knows it when one sees it?
Yes, and in the early 90's when the studies I've seen wre all
done there was little established precedent and few art critics
around to advise...
> In the end, though, the most effective tool is review by experienced
> peers. Where I worked before retiring we were top heavy with superstars
> and collectively had a century+ of OO experience.
In 1990 we had around 20-30 OOP experienced folks, by 1998 there
were a few hundred. Now we probably have around a couple of
thousand (out of about 6-8000 developers).
But all the studies I've seen were in that early 90's period
which makes their validity suspect. And with no new studies its
hard to be objective about how successful OOP has really been in
the maintenance arena.
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
- Next message: christopher diggins: "Re: The Failure of OOP"
- Previous message: Shayne Wissler: "Re: xp and simple design"
- In reply to: H. S. Lahman: "Re: The Failure of OOP"
- Next in thread: H. S. Lahman: "Re: The Failure of OOP"
- Reply: H. S. Lahman: "Re: The Failure of OOP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
