<>
Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to see it as a soap bubble? - Alan Perlis, as quoted in the Preface to Structure And Interpretation Of Computer Programs
One of the first proponents of Object Orientation was Ivar Jacobson, author of Object Oriented Software Architecture and Software Reuse. In both books you find the following idea: Object Orientation is important because you don't have to write the same functions over and over, you can reuse your code.
So Ivar Jacobson proposed that Reuse is what we are trying to achieve, Object Orientation is the road and UML is the car.
If Reuse Has Failed it means the Object Orientation Has Failed. With tears in my eyes, and after a decade of using successfully Object Orientation, I have to agree, some people still doesn't get it. Most Object Oriented solutions still can't be reused, so the success criteria is telling me we have not achieved the goal, no matter how hard we try, if we market Object Oriented solutions as reusable, we must be able to reuse them.
If REUSE has failed, perhaps REIMPLEMENTATION has succeeded? Further down some comments led me to think that the OO undertaking has enabled the discovery of patterns. If true, then certainly the creation of new applications at the same site have benefited from shortened development time, improved robustness, etc.
Maybe REDEPLOYMENT of selected portions of the application have been made possible through the use of OO techniques. If true, then reuse has succeeded on a macro scale. Otherwise when there is a technology/business change, then the entire application has to be started from scratch again.
I am not sure whether my assumptions are backed up by practical experience or not. I have lots of legacy Big Iron background and am therefore a willing learner from practitioners with years of OO experience in Enterprise computing. -- David Liu
Ah Ha! Just the dialog I was looking for. I reached the same conclusion awhile back at Object Oriented Refactored. I think what you'll find is that Wiki and OOP need to merge and create a Data Ecosystem. --Mark Janssen
There are some missing players in the statement "reuse has failed".
Reuse [of what] has failed [to...]
Cost savings due to reuse of code developed using OO techniques have failed to meet [someone's] expectations.
Cost savings due to reuse of code developed using OO techniques have failed to meet the expectations of CXOs who were sold [by someone] on the idea that reuse through OO would save them more.
With the missing pieces filled in, this looks like a familiar stop along the high tech hype cycle: to sell the decision makers on a new technology, big promises are made. Though benefits from the new technology are often evident to those involved, the promised made to the decision makers aren't realized, and they feel burned. -- Dave Smith
The claim Reuse Has Failed can also be considered another step (1. Push over the sacred cows) in the great hype cycle of sales for the Next Big Thing.
Like Dave, I think that saying Reuse Has Failed leaves some things unstated. Specifically, I think it's a bit too harsh to say that Reuse Has Failed just because, contrary to what some hand-waving salespeople have said, OOP doesn't automagically make code reusable, and "OO != reuse". Perhaps its just that Reuse Is Not Free, contrary to what I'm told a lot of people in some places think.
I'm quite happy with the amount of code reuse that I get, both with and without OOP. In practice, the only thing that's really hit me hard in limiting reuse is software licenses. "No problem, I wrote some code to do that a year ago. Oh wait; I was working somewhere else then, we'll have to just hack something up instead" or "I know an excellent package that can do this. Oh wait; it's GPL'd and our license is incompatible" and so on. But that's just my personal experience. -- Luke Gorrie
As an aside (I don't know where I should put this, and I don't want to start a new page), inheritance is one of the worst techniques of reuse I know, from both structure's and readability's point of view. Generic routines (Higher Order Functions with Parametric Polymorphism) are one of the best... layered handling and delegation is Good Enough.
There's something very hackish to the idea of reusing code by overriding selected parts of a class's code. Some beautiful hacks can be made that way, and the mess of what method is defined where very quickly gets unmanageable.
To me, OOP is not synonymous with reuse, quite on the contrary: the "one big point" of OOP is interface definition, which actually discourages reuse by inheritance. (I'm a little bit radical and think that inheritance should actually burn in hell.) OOP aims towards modularity. If you want reuse on top of that, reduce the complexity of operations inside objects to a minimum and define generic routines that use objects to accomplish complicated effects.
It's important to understand that you should not share code between two tasks because it is operationally equivalent but because it is semantically equivalent. If you extract a semantically well-defined part of code into its own unit (function, for example), you only get advantages every time you change the code, never unwanted side-effects.
There are those of us out there who were and remain skeptical about reuse in any technology. Reuse Has Failed is easier to agree with than Oo Has Failed. OTOH, I predicted and saw failure of reuse with objects (I first described it publicly in 1992) - I see it still, with people reinventing Java elements that supposedly were commercially available in C++ and Smalltalk - but the EJB and other Java bean phenomenon is giving some hope. The industry hasn't played out that strand of possibility. If Java beans don't make it, then I can keep being the reuse pessimist, otherwise I'll perhaps have a second counterexample in the kit bag. -- Alistair Cockburn
Perhaps successful reuse is invisible? Any technology that is not like magic is not sufficiently advanced! A new technology is a nine days wonder when first used and then a ho-hum, we all do that, forever after. Example: You use a High Level Language and libraries - you are reusing code - and it is obvious and non-sexy so it doesn't sound like a successful reuse technology.
The Jelly Bean Problem: the more alternatives, the harder the choice becomes. In the case of reuse: the more reusable stuff there is, the harder it is to find the right thing to reuse.
-- Dick Botting
The Jelly Bean Corollary: 99% of the jelly beans are vomit flavoured.
Have you been burned by a reuse failure lately? It sounds like you have a specific case in mind. -- John Brewer
[Response from Anonymous Donor saying that component based reuse (ActiveX/COM) is very successful - was lost.]
The mining and reuse of patterns has been a gold mine.
Agreed. -- sg
See Also: Pattern Backlash
And for those who think one language can solve all the world's problems and brew coffee too, don't EJB's give you hope in the server-side space?
Merry Christmas!!! -- sg
Grids and logging components are in the top 10 most reusable components. I've seen that reuse has helped people I've been around over the years temporarily raise the level of abstraction. And it's only really been successful when it's been local. I'll throw this out:
Reuse Inversion Principle: If you can't download it from the Internet, then one over the distance (in meters) between the consumers of a component and its producers is the chance you'll have at getting value from it.
Hence, you're only likely to be successful at reuse if it's being developed by or within the group that's using it.
One time at a bank, I helped a separate team building extensions to a desktop application for traders and analysts get a vertical slice of a calendaring app up and running in a few days. This was possible because we'd built a set of reusable objects. And since we'd used an adapter for our usage of a grid component, they were able to subclass our base adapter and use a grid from a different vendor. Key success factors were that we were keen about what needed to be common infrastructure, and that we had solid experience developing reusable code.
First Union National Bank made an early (and vigorous) commitment to Smalltalk, and invested significant time and effort trying to get reuse working through typical bureaucratic approaches. A central team was created that was responsible for maintaining a repository and harvesting reusable artifacts, individual project teams were supposed to offer up pieces of their application for reuse. The result? Little (if any) reuse across project teams. The few good opportunities that arose were undermined by technical, logistical, or political problems. I think of this attempt as a "socialist" reuse program, where everyone was supposed to act for the good of the enterprise, regardless of the impact to their specific project team.
We are now actually achieving some significant reuse across not only project teams but major lines of business through the work of the Do It team. We essentially act as subcontractors to line-of-business development teams, taking on applications or components that the primary team doesn't have the time, expertise, or stomach to build. We especially like it when we get to build components that we can use across lines of business - acting as an internal software vendor, we spread the cost of this development across the various business units. Project teams are incented to use us because we deliver faster time to market, reduced cost, reduced risk, and the promise of a scapegoat in case something goes wrong (fortunately, our application of XP practices and our outstandingly talented team have so far kept that from occurring). I think of our current efforts as a "free market" reuse program, and have been pleasantly surprised by its success. Project managers are led "as if by an invisible hand" to pursue the common good.
There are several differences between the old and new approach:
Component reuse versus source code reuse
Distributed middleware gives platform independence
We're not building reusable frameworks - we're building things that specific projects need right now (that work!)
We ARE scoping our projects with an eye towards reuse right from the beginning, rather than hoping to stumble on reuse as we go. -- Bill Barnett
I worked on a project once that included several large reusable modules. Of course, these were a source of pain for development. The interesting thing is that, since this was an XP project, much of the pain communicated through to the customer, and not just in reduced development velocity, but as real pain. In one case, the added specification complexity (a customer responsibility on this project) lead to the customer requesting the abandonment of a module. The customer concluded "it would be a lot easier for you guys to just write what I want rather than me figuring all of this stuff out." -- Ward Cunningham
What does this imply for Component Based Development? Can it possibly be more expedient to suffer through integrating a bunch of different vendors' components than to just write what the customer wants from scratch? -- Randy Stafford
Reuse [of what] has failed [to...]
Moderate scale, black box reuse of software has failed to be highly useful. Speaking from a C/C++ perspective, reuse of low level library routines has been so successful, many programmers fail to differentiate between the language and the library routines. Likewise, reuse of large modules (including whole applications) has also been commonly done. Most shell scripts are examples of this. The common threads between the two successful types of reuse are well-defined internal data types and well-defined operations on the data types.
The area that has failed is intermediate sized objects and components. At the intermediate level, we are usually trying to solve a particular problem using the general purpose low-level and high-level modules available. It is very difficult to compose a problem-specific solution with a wide level of appeal. This is where white box reuse has been successful. Take existing source code and modify it to fit the task at hand.
Much of the frustration with reuse has come from mid-level GUI components. It is very frustrating to adapt them to problem specific applications. Two big areas are data validation at entry and data storage. An example of the latter is use of a grid display without a database for data storage. I often wonder whether these components actually reduce the level of development effort or merely reduce the skill and knowledge level needed to implement the graphic interface.
Reuse at the low end and high end has been common place. Reuse at the middle level where much of the application specific glue between the low level and high level exists, does not seem promising.
-- Wayne Mack
Object Relational Mappers produce large amounts of code from a database. The code appears repetitive and reuse does not get used among components. This may relate to the midlevel reuse problem. A possible solution is a proper factoring between Data Oriented and Information Oriented techniques. Rather than having one new class for each table in a database, one could have some generic code for doing things like updates, inserts, deletes etc and drop table specifications into them for them to process. These specifications would be a form of information rather than being Data Oriented because the context of each column would be non-literal within these methods. Each of these methods would be reused over many of the tables in the database rather than having a version of each of these methods existing for each table. The benefit would be that these methods would be available for developing middle tier code and reuse within middle tier code would operate off of these methods. Add in En Demes for characterizing the tables and therefore writing the middle tier code, and you have significant potential for reuse of mid sized components. -- Jon Grover
I have found that if a function can be described as a 'service', it can become part of the programming infrastructure and can be reused, e.g. for logging. Unfortunately, that is not what most business types understand by reuse, and so the problem arises. -- Richard Henderson.
For some Advo Gato discussion of code reuse and its limitations, see www.advogato.org 
and www.advogato.org
The benefits of reuse are seen when we drop in a database (e.g. Oracle, My Sql, etc.) a web server (e.g. apache) and so on with out even thinking of rewriting these "components". We reuse languages, libraries, operating systems, development processes, firewalls, middleware etc. Then we complain that we didn't get enough reuse with our source code. -- David Plumpton
I don't think one needs OOP to do that effectively. But it is generally true that reuse in any paradigm has worked better with certain tools such as databases, graphics libraries, network interaction libraries, device drivers, etc. Where it has failed is in domain-specific areas, especially business modeling. I remember seeing huge Fortran libraries that did pretty much what the libraries of today do. The areas of applications where reuse tends to work and not work have not changed much over the years.
I agree that the statement "reuse has failed" is somewhat open-ended. It doesn't even state context. For example, as a possibly Off Topic argument for Reuse Has Failed , I could say that dumpsters are a sign that material resource reuse has failed, and refute it by using recycling or Dumpster Diving as an example of how it has not completely failed. In a more On Topic argument against Reuse Has Failed, I could cite specific instances, where I have used parts of one program to build another, or where I stripped down a mIRC bot to its base script lines and rebuild it from there for a much better bot.
In the late 80's and early 90's, "reuse" was the number one selling point for OO. However, that claim has now moved down in rank among OO practitioners. "Easier to maintain" is probably the top claim now (although I disagree with that). Thus, Reuse Has Failed To Live Up To Expectations. However, that is too long a title in my opinion. So, Reuse Has Failed is fine IMO. Oo Best Feature Poll ?
I will agree the Reuse has failed if one expects companies to set up and maintain vast internal libraries of block box modules for reuse. Reuse in terms of third party libraries provided as part of operating systems, languages, or stand alone libraries was successful long before OO came into being. Reuse in terms of calling an application from another application has also been successful, with techniques ranging from pipes to SQL to ODBC to web services. I would also say that reuse within a single program has been successful and this is largely due to OO techniques.
Concerning reuse via internal corporate libraries, I believe that the cost of these libraries has been vastly under estimated while the benefits have been over estimated and the usable lifetime of library modules has been ignored.
I would enjoy a code-based demonstration of intra-single-program reuse being facilitated by OO. I am skeptical.
I am not sure this meets your level of proof, but in my previous experience in large C programs, procedural code would often have many functions that accessed and operated on common data elements. Each function would often duplicate chunks of code for the same operation. If one needed to make a change in an operation, he often had to track through dozens of implementations of the same function, some pure copy and paste versions, some tweaked versions, and some versions rewritten from scratch. A class essentially provides a code library of functions to operate on a common data element causing developers to reuse an existing method rather than copying it or writing a new version from scratch.
Why didn't the C crowd apply basic factoring instead of reinventing the wheel? If they don't bother factoring, what is going to keep them reinventing the same classes over and over?
Andrew Koenig and Barbara Moo wrote in Ruminations On Cee Plus Plus that Library Design Is Language Design. Language design forces reuse; (proper) library design does the same. I agree with Bill Barnett's First Union National Bank example.
Argument: Software Development Isa Craft. We all need tools, and we must craft our tools and refine them: we use those tools when we build houses for our clients. Reuse Has Not Failed, as language has not failed (Believing Abstractions).
Another thought: why does reuse have to occur at the code or library level? Why not link programs together with a pipe? awk and sed are good Resuable Components.
I would suggest that Reuse has failed to eliminate the need to use programmers to do programming.
My interpretation of the unstated expectation was that if there was a sufficient library of objects to be reused, then someone sitting at a graphical CASE workstation or UML workstation could simply draw lines between various objects and a program would pop out.
There appears to be a belief that entering text via a keyboard is some how wrong and demeaning. I think there was an underlying hope that OO would eliminate or greatly reduce the need for programmer-typists and allow programs to be created by software architects using graphic modeling.
From a programmer viewpoint, however, Reuse has resulted in fewer lines of typed code, so it is a success. The reduction in typed code has probably been significant, but it is no where near total elimination.
-- Wayne Mack
One of the problems with reuse of mid-level components is that this is where much of the business logic goes.
The really low-level mechanical stuff (how to copy strings, open ports, send/receive packets, read/write files) really only needs to be defined once.
High level tools (like an application or, indeed, a whole language) get reused as long as their context is valid, which may be years or decades.
The business logic suffers from the tendency of management(s) to operate in fads. The "science" of management changes with the tides, so business rules get knocked about, and things that ought to be reusable are "obsoleted" by "new" management methodology.
No, this is not the only factor, just one that I've observed. Bookkeeping methods are reasonably low level, but deciding how to categorize stuff that is sent to bookkeeping is subject to capricious change.
Any module that implements a "why" may become non-reusable at a stroke.
Software reuse is in fact very successful. Think about starting a new big project. What might you reuse without even think about it? OS, Web server, app server, database, programming language, version control, utilities, IDE, etc. And then you complain that you didn't get enough reuse in your code. ;-)
Nobody says "Okay, time to write a web server and database". They just drop in Apache and Oracle (insert favourite products here). -- David Plumpton
I don't think, that Reuse Has Failed. I rather think, that Companies Have Failed To Reuse.
Related: Are Business Apps Boring
See Also: Oo Has Failed, Object Oriented Refactored
See original on c2.com