Oo Has Failed

It has? In what way?

Reuse Has Failed: For people expecting wide-scale high-level reuse to blossom just because their people start using OO tools, OO has failed to meet their expectations.

This would seen to indicate a failure of expectations rather than a failure of OO.

Some anecdotal evidence suggests projects constructed from carefully built abstractions get clobbered by projects that throw together some stuff in Visual Basic and Microsoft Access. There are certainly counter-examples, but the preponderance of evidence is on the side of reusing abstractions provided by a vendor and not creating new ones yourself.

This is like saying that hammers fail because most people have others build houses for them. OO can't fail nor can it succeed, it's just a tool. It's up to engineers to use it wisely. Those that do will find it a powerful tool indeed.

No, but if the paradigm had hoped to deliver things like "reuse", then it has failed.

Hardly. Reuse snuck in when no one was looking. We now re-use Open Source code on a massive scale in any of the popular programming languages, and OO certainly facilitated re-use of code within projects by providing a means to define abstractions that can be re-used.

{Is there a way to measure or demonstrate that OO is "more powerful"? Or, is this the wrong topic to ask?}

Are not the 'clobbering' claims also vendor supplied.

In part, that means that people are prepared to accept crappy software, to which I say: I don't care. I will find someone who wants quality - somebody doing XP, or something like it - and work for them.

(But that does sound a little arrogant)

Somebody has to create the abstractions in the first place.

Quality is fitness for purpose. The road to hell is paved with imagined ideas of quality that don't come from listening to the code or customer.

I don't think Access is Right Livelihood for me.

Something ugly delivered now might be better than something great in a month's time. Often it's not, though it might feel like it at the time.

I'm sorry but I haven't seen this. I have yet to see a SINGLE project of any scope where a well-organized OO team has been "clobbered" by a bunch of VB guys. On the other hand, I have seen many cases of the opposite, where VB and/or Access has failed miserably to scale and been replaced by a well-written, extensible Java, Smalltalk or C++ application.

Show me the money, dude. Either point me to hard facts (magazine articles, preferably with statistics, surveys, etc.) or admit that this is hearsay and "conventional wisdom".

-- Kyle Brown

"Well-organized" may be the key, not the language.

Think about this in terms of things we often have more appreciation for: grep, awk, maybe perl. Written quickly, written in Access ... these things don't mean ugly. One of the C3 guys wrote an Excel VBA thing that lets a salary administrator export her spreadsheet directly into payroll. That ain't ugly, dude, that's quick, efficient, even kind of elegant. Definitely habitable. The Quality Withouta Name, if you ask me. -- Ron Jeffries

"OO Is Not All That Bad" said my round table colleague (an OO expert). He said, "I just joined a project written by classic C programmers, and... (he related several interesting and horrible experiences)... and it has been a really long time since I have seen code written that way. And there is a lot of code out there written that way. So I just want to remind myself out loud, that OO is Not All That Bad. In fact, I really like it." -- Alistair Cockburn

The 'any scope' seems to be the key point at issue. Scripted solutions produce a good return on small scale projects, but that return diminishes as the scope grows. Carefully built abstractions are counter to this, they produce a limited return on small scale projects, but the return increases as the scope grows.

I am not sure how Component Based Programming solves problems that OO couldn't. I don't consider "reuse" a problem to be answered, but a tool used to solve real world problems (quicker, with less investment in development and perhaps fewer bugs).

Reuse is good, but whole hog code reuse can cause you to generalize too much. I need components that are very configurable, else I run the risk of ever-so-slightly modifying the problem to meet the solution. I am talking about customization. No two customer problems are ever exactly alike. (Poorly designed) coarse grain components may not take this into consideration.

My client may want spreadsheet-like functionality. I find a component that does spreadsheet stuff (perhaps a java bean). But, alas, it still looks like rows and columns of cells (my client didn't want a spreadsheet).

I have been frustrated (recently) by components that make assumptions about how I want to use them. The developers hardcode something (like a default time zone) and I can't get to it when I need to change it.

I don't think software development should be like Lego building. Lego bricks are great for building approximations: Sure, I can build a wheel out of Lego bricks. It will be mostly circular. But, what I really wanted was a wheel...

Ack. I feel about Component Based Programming (as defined by hype) the same way I feel about Case Tools.

-- Todd Coram

I suppose they could envision getting great gas mileage out of a Volvo and then write an article about how they aren't getting the mileage benefits they had envisioned. I and others like me have been telling execs since 1994 not to expect reuse from OO. But our feeble publishing skills are no match for the free-reuse hype generated by people with things to sell, which sell better alongside the free-reuse line. I managed to finally stop one project from starting, on the grounds that they were justifying OO in order to get free reuse. When they learned that wasn't the case, they stopped the project (wisely, I believe).

Never mind what execs "envisioned" as the benefits of OO reuse, I am concerned that the programming community hasn't learned Parnas' 1972 lesson [On Decomposing Systems] about encapsulating design decisions, and are whacking at the keyboard with the latest rage, Java in this case, programming the way they did before. The failure of OO, to me, is in the minds and hearts of tens of thousands of programmers, who haven't gotten it, and probably at this point, still won't for at least the next decade. So the industry has "moved on" without incorporating the dominant lesson of OO - encapsulation of design decisions. -- Alistair Cockburn

What I think has happened is that OO has failed to really provide significant re-use benefits. That's OK because Oo Is Not About Reuse. The problem is that in the past re-use has been pitched as a major selling point of OO. In fact, this was pitched so hard that many people seem to confuse OO with re-use. Anybody who conflates OO with re-use is likely to conclude that OO has failed. People who think OO is about something else will not draw this conclusion. -- Curtis Bartley

Actually, I think OO is hard. In procedural programming you can sort of start at one end and meander around and sooner or later maybe answers are coming out. Objects make that kind of coding harder, not easier.

Ordinary COBOL is a good comparison. You might write a subroutine paragraph from time to time, if you think of it, but mostly you just go along from beginning to end until done. Doing the same thing in objects, you get some big method and all the OO guys tell you that you have to break it down. You break it down and they tell you that you have to break up your class into separate classes. You do that and lo and behold they make no sense (because objects are hard) and you have a program that is harder to write and understand than the big blob would have been.

It has always been hard to write really good code. Objects make really good code easier to write. IMO, objects make it harder to write decent code than it was in procedural. Most programmers are in the decent range, so OO doesn't help them. -- Ron Jeffries

Objects aren't 'hard'. They are quite soft and pliable. Thinking too much is what makes objects hard. Don't think... just do and all will be easy. The big problem with OOP (driven by websites like this) is that people spend far too much time thinking and not enough time doing.

I just reread the first paragraph: "There is considerable evidence that projects that carefully build abstractions get clobbered by projects that throw together some stuff in Visual Basic and Access?....the preponderance of evidence is on the side of reusing abstractions provided by a vendor and not creating new ones yourself."

I first notice that this was unsigned, and then noticed the vagueness of the claim. So if anyone has any evidence, it would be great to see it mentioned.

But the last phrase is interesting separately. I do agree that "reusing abstractions provided by a vendor" is faster than inventing new abstractions on the project. The trick has always been: how do you get people to do this? The class libraries provided by vendors have always been good examples. Java Beans have moved things along. The matter of using vendor-provided abstractions is separate from OO as a programming model - and I think it could make an interesting discussion to consider the different flavors of vendor-provided abstraction, and what makes them accepted and used, or not. -- Alistair Cockburn

If you ask me and many others, OO has failed. That's why COM, CORBA, and Java Beans/RMI/EJB were invented. -- sg

COM stands for Component Object Model. CORBA is Common Object Request Broker Architecture. RMI is Remote Method Invocation. Java Beans is just a way of packaging Java objects with easily discoverable names for their accessor and mutator methods. These are all object-oriented technologies. They just move OO to a higher level of abstraction than before. -- John Brewer

This all strikes me as rather odd. How has OO-reuse failed? When I see OO-systems, I see reuse anywhere. In Java, you can simply inherit from an Applet-class to make your new applet. That's reuse. The new Swing JApplet class inherits from Applet also and you can inherit from it. That's reuse. You don't have to build your new stuff from scratch to make it possible for code to run in a Java-enabled web-browser. When you want a new kind of text field, simply inherit it from TextField and add your new stuff. Reuse again. Behavior of RMI-objects can be re-used by inheriting from Unicast Remote Object. The same kind of mechanism holds true for CORBA-objects in Java. Also in other OO-languages, like Smalltalk, Eiffel or C++, systems get assembled and extended by inheriting classes or assembling classes from other ones. The OO-projects I am involved in usually have made thankful use of reuse in this way.

So why all the talk that it failed? Maybe the amount of code that can be re-used has been over-estimated? I think that if a system can be developed with 50% reusable items, that is pretty good! It's also only logical: you can reuse only so much. Every system has its own requirements. But even when classes and objects can't be reused as-is, they often still can be used in a slightly altered form. That may not be the 'black-box' reusability propagated by some OO-experts, but it's still very usable indeed.

And when does someone ever realize that CBD is nothing more but a deployment-method? Instead of deploying a library as a set of classes, you simply hand a developer instantiated classes, that can be manipulated in a container of some sort. In some cases it's handy, in other cases the static nature of a ready-made-instance may be too restrictive. It's no silver bullet.

-- Richard Smol

I think there is plenty of OO reuse about. The most important re-use is reuse within a project. OO system manage dependencies within software, so its maintainable life is increased (maintainable means that it remains possible to add arbitrary features - many legacy systems survive beyond their maintainable life).

I think certain types of reuse have failed. I think company-level reuse has failed. I've never seen any company that has a large central repository of source code to draw upon. I regularly marvel, however, at the amount of code I can draw upon in the Java standard libraries. To me, this is enough. -- Glen Stampoultzis

This is where I think, OO reuse has failed. It's not the fault with the OO. It's the fault of IT Managers. I have seen code being reused maximum up to the level of one or two projects inside a company (vendor provided components and frameworks do not count). Problem is that people do not know of the large amount of code that can be reused. This has lead people to believe that OO has failed. The problem is not of the OO technique but of management of object oriented code. -- Vh Indukumar

[The below text was removed without giving a reason]

It seems like it is agreed that "library API's" and intra-application reuse is relatively successful, but company-wide reuse is a dud so far. Vh Indukumar's solution seems to be more nagging and cajoling. But why does it "naturally" seem to work without all the cajoling in two areas, but not the third? In my opinion it is that one cannot reuse stuff with lots of alterations for each new app. Either we copy it and make needed adjustments for a particular app, or keep adding features to the central classes or framework. The number of features needed to make it a truly "generic" thing keeps climbing and climbing so much that it becomes too complicated to manage and understand, so nobody touches it anymore.

Things like networking API's don't really have this problem because they are tied to relatively stable standards set by W3C or what-not. At the app-level, feature quantity is kept stable because it only needs to satisfy one app. At the standard library level, it is kept stable by external standards bodies and the slow process of shared review and adoption. There is too few forces to cap off runaway feature counts for company-wide generic-intended libraries. It just seems easier to copy a bare-bones or similar one, and modify it for local app needs rather than integrate our particular needed features into the central copy. This is still reuse, it is just "copy-reuse" instead of "reference-reuse".

But I wonder how much you have gained over and above, say, an old style 4GL (which if you think was simply a reusable application framework)? I have to say that I think OO has become a religion to some. Anybody who suggests a different method of system organization is treated like a heretic.

I am not sure what this comment means. Object Oriented what has failed? How is failure measured or determined?

It's determined like this: the "GDP" of objects floating around the Data Ecosystem.

Clearly Object Oriented languages still exist and appear to be popular, even though they haven't supplanted all procedural languages, and some languages are hybrids. I would be hesitant to call that failure.

Program size has continued to get larger, especially when using object oriented languages. It would seem to me that OO has succeeded in allowing more complex programs to be written.

If somebody wanted Empirical Evidence of this, could anyone provide such? Look at the memory sizes in new PCs. How many programs today could run in the 256 KByte machine of 20 years ago? I meant allowing more larger/complex software. The statement merely said that larger program size seems to be time correlated with adoption of OO languages. The author then stated that this implied to him that OO allowed larger programs to be written and that largeness implies complexity. One can disagree with his implication, but I believe the basic statement of time correlation seems to be true and appears interesting as well.

Can anyone clarify and justify the "OO allows more complex programs" statement?

How many programs of 20 years ago had to load more than curses-like gui. I don't have Unix at hand right now, how big are today's versions of the CLI programs?

"Curses"? In my opinion, GUI info for most custom business applications should use Meta Data (such as XML or relational tables) rather than in-code setups of GUI's and GUI attributes. I will agree that OOP-based GUI's are popular, but I think it is mostly a fad or Qwerty Syndrome. Meta Data-based GUI's are probably more resource intensive, and 10 years ago this was important. But, computing power is now sufficient to start looking at alternatives. For one, it is difficult to make a good language-neutral OOP interface (SOAP is not "good"), and reinventing the GUI for each language is counter-productive.

OOP is a nice modularity-related tool for certain situations in certain spots of code, but didn't live up to its original hype of reuse and transforming software engineering in general. It's just as important to know when to use it as when not to, and to use it right. Simply stuffing code into classes or objects based on superficial or quick guesses does not by itself make code better. One has to know what to stuff where and when in order to get a net gain. It gives our software engineering palette more colors, but doesn't tell us how to paint. --top

See original on c2.com