C Language

Reuse It Or Lose It

Although there's no "silver bullet" for software development, code reuse is about as close as you can come to a technique that dependably reduces development time and increases software reliability. The reason is simple - you will save time, if you can supply a component of an application by reusing an existing one rather than building a new one from scratch. And if the reused component has proven its reliability in previous use, its performance in a new application is likely to be better than a newly created component that undergoes its first production tests in your application.

Most programmers and managers know the value of reusing software components; the problem is they usually don't have a rich set of suitable components available when they start a new project, so they're forced to build what they need. More often than not, deadline pressures and limited resources keep newly built components from being implemented so they can be reused on future projects &151; and the problem propagates through another project cycle.

The fundamental barrier to reuse is economic: Reuse pays off only across projects and over time, but requires investment in the short-term. It's expensive to build and catalog reusable components, so unless an organization has some financial practices that distribute the component supplier's costs to the consumers of the components, nobody will build for reuse.

The economics of reuse suggest an easy solution: Buy reusable components, if suitable ones are available. One of the undeniable advantages of developing applications in C/C++ is the large number of source and executable libraries available as commercial products. For standard system functions, such as file systems, user interfaces, and communications and connectivity, commercially available products are often of higher quality and lower cost than if you developed them from scratch. These packages are so inexpensive for MS-DOS and Windows environments that a reasonable strategy is to buy multiple products that cover the same areas, try them out in your own program development, and select the product (or parts of each) that satisfies your requirements best.

Although developing your own reusable components is more expensive, it is sometimes necessary for application areas not covered by commercial products. As I mentioned earlier, it's essential that the organization recognize the cost and value of building reusable components. This may take the form of an explicit method of project accounting, or it may be implicit; for example, by assigning some staff the primary responsibility of "component builder."