Reuse Has Failed
Reuse Has Failed<<This page needs refactoring>>
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? - AlanPerlis, as quoted in the Preface to StructureAndInterpretationOfComputerPrograms
One of the first proponents of ObjectOrientation was IvarJacobson, author of ObjectOrientedSoftwareArchitecture? and SoftwareReuse. In both books you find the following idea: ObjectOrientation is important because you don't have to write the same functions over and over, you can reuse your code.
So IvarJacobson proposed that Reuse is what we are trying to achieve, ObjectOrientation is the road and UML is the car.
If ReuseHasFailed it means the ObjectOrientationHasFailed?. With tears in my eyes, and after a decade of using successfully ObjectOrientation, I have to agree, some people still doesn't get it. Most ObjectOriented 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 ObjectOriented 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 BigIron background and am therefore a willing learner from practitioners with years of OO experience in Enterprise computing. -- DavidLiu
Ah Ha! Just the dialog I was looking for. I reached the same conclusion awhile back at ObjectOrientedRefactored. I think what you'll find is that Wiki and OOP need to merge and create a DataEcosystem. --MarkJanssen
There are some missing players in the statement "reuse has failed".
The claim ReuseHasFailed can also be considered another step (1. Push over the sacred cows) in the great hype cycle of sales for the NextBigThing. -- MartinSpamer
Like Dave, I think that saying ReuseHasFailed leaves some things unstated. Specifically, I think it's a bit too harsh to say that ReuseHasFailed 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 ReuseIsNotFree, 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. -- LukeGorrie
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 (HigherOrderFunctions with ParametricPolymorphism) are one of the best... layered handling and delegation is GoodEnough.
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. ReuseHasFailed is easier to agree with than OoHasFailed. 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. -- AlistairCockburn
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 HighLevelLanguage 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. -- DickBotting
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. -- JohnBrewer
[Response from AnonymousDonor 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: PatternBacklash
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.
FirstUnionNationalBank 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 DoIt 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:
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." -- WardCunningham
What does this imply for ComponentBasedDevelopment? 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? -- RandyStafford
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.
-- WayneMack
ObjectRelationalMappers 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 DataOriented and InformationOriented 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 DataOriented 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 EnDemes for characterizing the tables and therefore writing the middle tier code, and you have significant potential for reuse of mid sized components. -- JonGrover
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. -- RichardHenderson.
For some AdvoGato discussion of code reuse and its limitations, see http://www.advogato.org/article/127.html and http://www.advogato.org/article/150.html
The benefits of reuse are seen when we drop in a database (e.g. Oracle, MySql, 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. -- DavidPlumpton
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 OffTopic argument for ReuseHasFailed , I could say that dumpsters are a sign that material resource reuse has failed, and refute it by using recycling or DumpsterDiving as an example of how it has not completely failed. In a more OnTopic argument against ReuseHasFailed, 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, ReuseHasFailedToLiveUpToExpectations?. However, that is too long a title in my opinion. So, ReuseHasFailed is fine IMO. OoBestFeaturePoll ?
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?
AndrewKoenig and BarbaraMoo wrote in RuminationsOnCeePlusPlus that LibraryDesignIsLanguageDesign. Language design forces reuse; (proper) library design does the same. I agree with BillBarnett's FirstUnionNationalBank example.
Argument: SoftwareDevelopmentIsaCraft?. We all need tools, and we must craft our tools and refine them: we use those tools when we build houses for our clients. ReuseHasNotFailed?, as language has not failed (BelievingAbstractions).
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 ResuableComponents?.
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.
-- WayneMack
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). -- DavidPlumpton
I don't think, that ReuseHasFailed. I rather think, that CompaniesHaveFailedToReuse.
Related: AreBusinessAppsBoring
See Also: OoHasFailed, ObjectOrientedRefactored
EditText of this page
(last edited December 23, 2014)
or FindPage with title or text search