The politics of reuse - software code reuse - includes related article on achieving reuse - Technology Information

Software Magazine, Jan, 1997 by Tony Baer

Visual, object-oriented 4GLs and powerful modeling tools make software reuse possible, but project and organization management skills make it happen

It's human nature to want to build a better mousetrap. Developers are no exception. "If you let the application folks just go at it, they'll always think that they can do a better log-in screen," says Roj Snellman, a senior manager for architecture design at Harris Semiconductor in Melbourne, Fla.

The problem is, there's not enough time to do all the fun stuff anymore. Rapid application development techniques have hammered in the notion that production-ready applications can happen within eight to 12 weeks, maybe even less. "Our customers aren't giving us the amount of time that we might have gotten a year ago," says Ric Lehman, national accounts manager for IMA Plus, a client/server consultancy in Jacksonville, Fla.

According to Lehman, "better, faster, cheaper" are the buzzwords among his customer base. Add to that list "fixed-price contracts," says Bill Barton, president of Tier Corp., a Walnut Creek, Calif.-based client/server development company.

One way to mitigate development cost and time constraints is to reuse software code. The emergence of powerful visual tools to automate growing portions of the application development life cycle makes the idea more a reality. What's more, most everyone believes reuse is possible -- just look at the market for third-party Visual Basic Controls (VBXes). Developers no longer have any excuse for reinventing generic Windows screen features such as radio buttons, tabs and pull-down menus.

And this is just a hint of things to come, says Mike Blechar, application development research director at the Gartner Group, Stamford, Conn. By the year 2000, he predicts, at least 60% of all new software applications will be built from components. Although components are still restricted to user interface features or controls, Blechar maintains they will evolve to encapsulate higher-value business processes such as task scheduling or customer identification. It's already happening in the enterprise resource planning (ERP) market, where vendors such as SAP America Inc., Wayne, Pa., are deconstructing integrated applications into plug-and-play components.

But progress is slow. "We've been successful on a few projects," says Brian Johnson, director of systems development at IMA Plus. Currently, the firm uses Power Builder class libraries, groups of reusable controls for user interface and systems administration functionality from the Concord, Mass.-based Powersoft Division of Sybase Inc.

Indeed, the majority of reuse today involves user interface and systems related functions. These include user interface features such as menu bars, radio buttons and other "widgets" associated with VBX controls and PowerBuilder class libraries, or systems functions such as standard log-in, sign-off, database connection and procedures. Reuse at this level is useful because it keeps developers from reinventing the core technologies of an application.

However, reuse won't come close to reaching its potential until the reuse of business logic is possible. Instead of merely saving developer time, reusing core logic can add value to the enterprise because it forces the organization to turn a mirror on itself, asking who does what, and whether there's any commonality -- or redundancy -- across different business processes. Identifying such commonality is at the core of business process reengineering no wonder most organizations have a hard time reaching this point.

Does the discipline required to ensure reuse stifle all developer creativity? How does an IS organization encourage its developers to reuse software when they may think they can do something better if they start from scratch?

According to Grady Booch, co-author of the Unified Modeling Language and chief scientist at Rational Software Corp., Santa Clara, Calif., reuse can't be mandated. Through consulting work, Booch has learned that positive motivation, not control, is the best way to get reuse. Project team members, he says, can either act as sales people, promoting their objects to other groups, or they can "scavenge" after a project winds down in search of objects or components that could be generalized.

Whatever motivation they use, few if any firms have been willing to dangle financial incentives in front of their developers. Among the reasons are questions over which code is actually reusable. "It's very subjective," says Darrell Parrish, vice president at MTW Consulting, Kansas City, Mo. In fact, he says, organizations that reuse code would probably admit to rewriting 90% of it.

Reuse also requires skillsets not always present in development organizations. A team approach is absolutely essential, says IMA's Johnson. There is a logical breakdown of responsibilities between people who develop generic components and those who deploy them, adds Snelling of Harris Semiconductor. Component developers are software engineers or senior developers who design standard components using process and object modeling tools. In some cases, qualified developers could take on the role of deployer.