The Business Case for Reuse

If you're managing a development project, you should seriously consider reuse-in fact, you should think of reuse as a requirement, not just an option. Whether or not you realize it, reuse is one of the most efficient ways of reducing development time and effort. Unfortunately, many companies develop each application in isolation, viewing each one as a single entity encapsulated within a particular budget. If you intend to implement multiple applications, you'll gain reuse benefits in the form of business components-that is, units of functionality that dictate specific areas of corporate policy. An example of such a policy is "Account managers may authorize discounts of up to 20 percent for regular customers." If you create a single business object to implement this policy for all customer accounts, you'll be able to enforce the integrity of this rule. You'll also have the advantage of being able to change the rule in a single place, which is an important capability given that business rules will change as company policies change.

Business components are not the only area in which you can benefit from reuse. Think of a company that starts each development from scratch, and imagine the number of times a particular unit of code (for example, an error handler or a FileExist function) is written. At TMS, we have a reuse strategy. We have an application template that contains core functionality such as error handling, custom messaging, and general utility functions. When we start developing a system for a customer, we give our client the option of purchasing the application template. This creates extra revenue for TMS but, more important, also cuts off about a month of development time because we start building code from this template, which has already been fully debugged and tested. Some companies have unassigned staff between projects with nothing to do. Using such downtime to develop generic "auxiliary" code-the type of code that gets written in almost every project-would be an ideal way to start gearing everyone toward the goal of writing reusable code.

Just because a component is designed for reuse does not necessarily mean that the component must be reused. One benefit of having encapsulated and loosely coupled components is that maintenance becomes much simpler. (Encapsulation and coupling are key elements of reuse and are explained in more detail in the next section.) Imagine a maintenance programmer fixing a bug in a component. If the component is totally self-contained, the programmer doesn't need to know anything about the application outside that component. This makes it easier to control changes in the maintenance phases and allows greater flexibility when allocating people to do the work. Another important advantage of encapsulation and loose coupling is that it's easier to identify components that need to change if maintenance work becomes necessary.

For those of you still not convinced that reusability has real benefits, think of the interface changes made to Microsoft Windows 95. If you're familiar with both Windows 95 and Windows 3.x, one of the prominent interface changes you'll have noticed in Windows 95 is the new look of the controls. Think for a moment of the humble command button. Command buttons previously had a 2-pixel border and bold captions. In Windows 95, the command button changed: the button border is now only 1 pixel wide, and the caption font is no longer bold. You'll also notice that these characteristics change automatically between the versions of Windows. This automatic change in appearance was possible only because the command button, as well as many other controls, does not draw its own borders and captions-a Windows function does it. Imagine the amount of additional development time that would have been required to change the drawing functions if each control had contained its own!