InformationWeek.com

Join Kevin Mitnick - the "most wanted computer criminal in the world" - as he shares his secrets on the security threats facing corporate America.

Welcome Guest. | Log In| Register | Membership Benefits

November 9, 1998

Print this story

Hidden Costs Of Code Reuse

continued...page 2 of 3

Illustration by Dennis Harms

Blue Cross/Blue Shield of Rhode Island used Sybase Distributed PowerBuilder to build several reusable server-side components intended to be used by multiple applications. It was used to create a customer-management application called Group Paperless, which lets clients change information about their insured employees. Such information might include the number of dependents or the type of coverage. Group Paperless uses business logic components deployed on a server to handle all updates to the database. Business logic determines the kinds of changes that can be made and how the changes are processed. Developers can leverage this business logic in other applications.

A second Blue Cross application uses a server-side infrastructure component, named PowerQ, to let developers access IMS transactions without having to write code to manage complex database APIs. PowerQ takes information requests from a PowerBuilder DataWindow and sends them, via IBM's MQ Series middleware, to IMS, allowing the company's PowerBuilder developers to quickly and easily send and receive MQ messages. As a result, Blue Cross developers avoid hand-coding IMS calls for every application. "We built a lot of business logic into the component," says Jeff Meyer, Blue Cross technology architect. "We did it once, and now it is done."

Of course, even if components are designed for reuse, changing business needs can still render them useless. Changing technology can also make components obsolete before they reach the break-even point in their life cycle. Even the best reusable software doesn't have a long shelf life, says McGregor. So organizations not only need to get four or five reuses of the object to make reuse worthwhile, but they need to do it quickly, before the component becomes obsolete.

Team Effort
A bigger obstacle than shelf life may be getting project teams to cooperate in achieving reuse in the first place. "You need some level of coordination among projects, but project managers are driven by the goals for their immediate project," says McGregor. Few project managers are willing to spend their energy and resources and risk missing their deadlines to build functionality that others might use down the road. When a project manager's rewards are closely tied to achieving the project goals, it's hard to be magnanimous and make the component robust enough for reuse, he says.

One solution is to add a layer of management bureaucracy in the form of corporate reuse policies. These practices should extol the benefits of reuse while enforcing reuse across the organization. This approach further increases the cost of the reusable component and pushes payback further into the future.

The proponents of reuse suggest having a specialized reuse group in place at the start of any reuse project. Reuse proponents don't expect application developers to build reusable components while they're building applications, says Cutter Group's Harmon. Instead, the central group designs the architecture, builds and maintains a library of reusable components, evangelizes reuse, and enforces architecture and reuse standards.

Development managers, however, generally resist the top-down approach, while conceding the need for some entity to coordinate the reuse effort. "We don't have anyone specifically managing a reusable component library," says Ray Touchette, engineering project manager at the Boston Communication Group, a telecommunications software company. Rather, developers on three teams, encouraged by their project managers, have sought reusability in components and have agreed among themselves to adopt reusable components for common business logic.

Still, Touchette wouldn't object if someone categorized and documented components. "It would help teams to understand what's available. Otherwise, we sometimes create multiple, similar components," he admits.

Schneider Automation Inc., a North Andover, Mass., manufacturer of industrial automation equipment, tries to avoid unleashing the "reuse police." "I don't buy into the need for a big reuse bureaucracy, but you do need some infrastructure to make reuse economical," says Allan Tate, program manager at Schneider.

The infrastructure, which may consist of little more than a source-code management tool--Rational Software's ClearCase, in Schneider's case--makes information about the components accessible. This infrastructure, Tate adds, might need to be only a simple search engine, as long as it delivers the information developers need.

On the enterprise level, however, Schneider employs a global architecture team. The team tries to ensure that all new components fit into the company's global plan, but the architecture isn't solely for reuse. "We don't need a group for reuse," Tate insists. Reuse is a natural side effect of good architecture, he adds.