Contents

What is Reuse and What is Reusable?

Reuse and Staying in Business

Where is the Component Market?

Where Is the Component Market?

We were supposed to get that productivity jolt from third parties who would create catalogs of reusable components, which the equivalent of software original equipment manufacturers would then assemble into applications. The sad fact is, not many components can be reused to the extent we’d like.

Every instinct we have as programmers screams out that there must be common components for software applications. Most programmers know that it’s rare to create something truly new. Good software professionals keep a mental backpack filled with previously used concepts they can apply when a familiar-sounding “new” problem comes along. Object technology seems to offer the tools to reuse these concepts as reusable components. Unfortunately, we may have confused the idea of common concepts with reusable components.

As an example, most information systems have a concept of a customer, and most customers have the same behavior: They purchase goods and services from an organization. The behavior of these customer transactions is rigidly specified by law and accounting rules. Is it possible to write a reusable “customer” component that you could sell? While the concept of a customer may be similar, the implementations can be wildly different. Could a financial institution use the same customer component as a petroleum company? Could two companies in the same line of business use the same customer component? Companies have different policies for handling customer transactions, so component vendors must either seek the lowest common denominator in their customer components or let the client modify the component. Most experts agree that if more than 20% of a component must be reworked for its new context, it is more efficient to start from scratch.

There has been some success in creating a commercial component market. Numerous infrastructure components are available for easing the construction of applications. A recent catalogue listed Windows development components such as grid controls, charting, and data visualization. Other vendors offer components for data management, thread management, and data sharing between applications. These types of components have helped developers deal with the increasing complexity of the application environment. However, commercial components have not catalyzed a fundamental change in the industry from handcrafting to assembly-line production—with the accompanying productivity increase.

Where Did All the Money Go?

When it comes to object technology, many companies appear to be riding a policy roller coaster, just following the ups and downs of wherever their software vendors take them. When you ask why they are investing in object technology, they usually answer that they want to improve productivity through reuse. The problem with this reply is that if object technology is justified solely on the basis of reuse, it can only lead to disappointment and frustration when a company’s investment does not achieve huge productivity gains. To date, I have seen several large companies abandon or dramatically scale back their client/server object-oriented strategies and revert to their rusty but trusty mainframes. These Fortune 1000 companies in telecom and financial services justified their failed projects on the promises of tool vendors and MIS managers. When the increased productivity did not materialize, or worse, when productivity actually dropped because the staff was learning the new technology, the projects were abandoned or scaled back. It is not fair to dump the blame for these project failures on object technology, but overstating the benefits of reuse probably did much to distort project risk management.

Systematic reuse for many companies is not economically justifiable because of the high up-front costs. Further, an open market of reusable components may be impeded by the fact that much software is simply not reusable. There are many common concepts, but few common components.

Is object technology, then, beneficial only to companies that can take a long-term view? In a word, no. The object paradigm has encouraged programmers to shift their focus from the implementation of concepts to the relevant abstractions of a concept—in other words, thinking in terms of black-box components, separating the interface of an abstraction from its implementation. This leads to more resilient programs.

Furthermore, while most of the reusable components available in the marketplace are infrastructure components, they do help programmers cope with the ever-increasing complexity of the user interface, data storage, and distribution.

Reuse and object technology are not the technological silver bullet we are forever searching for. If your justification for investing in object technology is based on an order-of-magnitude improvement in productivity from reuse, then save your money, because it’s not going to happen. However, if your justification is based on the premise of progressive improvement in productivity and software quality, then your expectations are more realistic. Finally, features of objects that facilitate systematic reuse also facilitate code salvaging. While salvaging code is not the same as reuse, every line of code you can salvage is a line you don’t have to write. Now that’s worth real money.

________________________________________________________

What is Reuse and What is Reusable?