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."
