InformationWeek

November 9, 1998

Print this story

Join our discussion in Reply To All. Code Reuse: Is It Worth It?

Hidden Costs Of Code Reuse

Code reuse seems to make sense-but many companies find there's so much work involved, it's not worth the effort

By Alan Radding

Illustration by Dennis
Harms

ode reuse has long been a goal that most self-respecting development shops aspire to. But in reality, large-scale code reuse is still more the exception than the rule. The value of software reuse is a notion that application development managers don't usually question. However, it's becoming clear to some who work in this field that large-scale reuse of code represents a major undertaking that may not be worth the effort in every case.

"Going after reuse doesn't make sense for a lot of companies," says Norman Kerth, a software development consultant in Portland, Ore. If companies have just one or two projects in mind for reusable objects, reuse won't pay off, he notes. Kerth found that it takes at least three times the effort to build a reusable part that it does to build a part for one-time use. So, if you don't foresee opportunities to reuse the part repeatedly, don't even bother designing it for reuse.

Building reusable objects requires extensive analysis and design. "You really need to understand what the generalities are," says Kerth. Then, you will need to invest extra time in testing and quality assurance, optimization, and documentation. All this takes time and labor, which increases the cost of the code. IT departments must also add to the payback equation the cost of tools to support reuse, such as version control and repositories. Finally, the cost of administering an ongoing reuse program must be considered. With all these elements, it becomes apparent that reuse doesn't come cheap.

Even so, companies seem intent on pursuing software reuse despite the extra work and the distant prospects of payback. Cutter Information Group, a technology research firm, found in a survey on the subject of object-oriented development among 120 large companies that 80 of the companies cited software reuse as a driving reason behind their adoption of objects. "Reuse is clearly the goal, although whether they will succeed in achieving it is still an open question," says Paul Harmon, director of Cutter's component development strategies service.

A similar study of 60 companies by the Standish Group found a unanimous belief that they would ultimately benefit from software reuse. Conversely, 70% of those surveyed reported failures with their first object application development effort. Success rates improved substantially in subsequent efforts. "The companies said they learned so much that it was well worth the cost of the failure," says Karen Boucher, a Standish executive VP.

Reason For Hope
But enough companies are succeeding at their code-reuse efforts to give others hope. Film studio 20th Century Fox in Century City, Calif., used Forté Software Inc.'s development environment to build a reusable component for capturing information about talent, agencies, and organizations--the parties the company works with in the making of a film. The component took considerably more work to build than if the team had built it for a single application. "We had to develop generic abstractions for things we might not have needed right then," explains Gregg Strode, director of project management and application development at 20th Century Fox.

Reusable Components
Different types of application code require varying levels of investment to achieve successful reuse

Reusable GUI objects reduce development time and improve quality and consistency but provide only modest payback in terms of overall application development costs.

Server-side components that constitute reusable business logic can provide significant payback but require extensive up-front analysis and design. They also require an architectural foundation but may experience a short shelf life.

Infrastructure components and services frameworks are generic services for transactions, messaging, security, and database connectivity. They eliminate the need to repeatedly build infrastructure that all applications use, but require extensive analysis and design, and complex programming. These standards-based components can often be purchased off-the-shelf.

High-level patterns allow organizations to achieve design reuse and identify components with high reuse potential, but developers must build or acquire the components.

Packaged applications provide the only guaranteed form of reuse, letting user companies acquire functionality for significantly less than the cost of building it themselves. However, these applications may not offer the exact functionality an organization needs; the subsequent customization that's required will add to the cost.

DATA: INFORMATIONWEEK

Strode was able to justify the increased development time and effort because he expected 20th Century Fox to use the component in one form or another in multiple applications. Not all those instances required the full capabilities built into the reusable component, but the team had to put them in from the start if the component was to be truly reusable. One application needed just a person's address. Another application needed the address plus information about the different activities and relationships associated with a particular person or company. Strode says that through multiple usage, 20th Century Fox's investment in the application component will more than pay off.

That's not always the case. "Often, reuse doesn't pay," says John McGregor, associate professor of computer science at Clemson University in Clemson, S.C., and a senior partner in Software Architects Inc. of Chattanooga, Tenn. It depends on the nature of the organization, its experience in managing software development, and the type of reuse it seeks. Not all reuse delivers equal payback, he says (see chart, left).

For example, reuse of graphical user interface widgets seems a sure bet. It's easy to achieve GUI reuse. In fact, with so many good reusable GUI components on the market, developers often don't even have to build any code. The Web is ripe with small developer sites offering well-tested GUI components. Many development tool vendors give away sets of such components.

GUI reuse, while helpful, is a small part of the big challenge enterprise developers face, says McGregor. GUI reuse will give a quick shot to your reuse rate, but it isn't going to make much of a difference in any application backlog or development budget today.

A bigger payoff comes from large-scale reuse of server components. These components typically capture critical business logic, such as the organization's complex pricing algorithms, or represent common business entities such as Fox's movie-making talent. These code components can embody what's unique about the organization and have the potential for widespread application use across the enterprise. They typically fall into two categories, business logic or infrastructure services.