The UP is developed with object technology (OT)projects in mind, and the adoption of OT has often been promoted in order to achieve software reuse. Significant reuse is a laudable goal, but difficult. It is a function of much more than adopting OT and writing classes; OT is but one enabling technology in a suite of technical, organizational, and social changes that have to occur to see meaningful reuse. Certainly, libraries of classes for technical services, such as the Java technology libraries, provide a great example of reuse, but I am referring to the difficulty of reuse of code created within an organization, not core libraries.
In a survey of organizations that had adopted OT, they were asked the actual value of its adoption. Interesting, reuse was at the bottom of the list [Cutter97] . Among experienced OT practitioners and organizations, this is not a surprise: They know that the popular press's description of OT for reuse is to some degree a myth; most organization see little of it. This is not to imply it isn't a valuable goal, or that there is no reuse—it is worthy, and there has been some. But not the high levels of reuse some articles and books suggest. And many an experienced OT developer can tell you a war story about the misguided large-scale attempt by an organization to create the grand "reusable libraries" or services for the company, spending a year and million dollars, and ending with a failed project, or one that misses the mark. Reuse is hard, and arguably more a function of social and organizational issues than technical ones.
Does this mean OT is without value? Not at all, but its value has been incorrectly associated primarily with reuse, rather than how it most prominently helps in practice: flexibility, ease of change, and complexity management. The same survey [Cutter97] lists the top values actually experienced by adopting OT: easier application maintenance and cost savings. Object systems—if designed well—are relatively easier or faster to modify and extend, than if using non-OT technologies. This is important; many organizations find that the majority of the overall long-term cost of an application is in revision and maintenance, not original development, and thus, strategies to reduce revision costs are important. Although it is rational to want to reduce new system development costs, there is a certain irony that few stakeholders ask the follow-up question, "How can we reduce the cost to revise and maintain it?" when that is often the largest expense. It is here that OT can make a contribution, in addition to its power and elegance in tackling complex systems.
From: Craig Larman, Applying UML and Patterns, an introduction to object-oriented analysis and design, 2nd ed. Addison Wesley, 2002, p. 601
