Initial attempts to build parts libraries were based on a trial and error process. Many things were tried, then iterations were made to modify the sources inhibiting success. This feedback mechanism benefitted the developers of our most successful parts libraries of today. In the non-code area, proposal and process libraries were built. The proposal library taught us that having the real experts take time to write the generic, reusable information is the only way to be successful. It is always hard to get these people's time, but it is a truism that they are needed. Although experts were used, some of the more technical areas written for reuse were not a reuse success. It was found that the technology changed so rapidly that the extra cost to make the information reusable could not be recovered before the information was no longer timely. Another problem with reusing very technical information is that the frameworks (customer environment, terminology, etc.) change so much that extensive editing is required for reuse. Templates have proven to be the most common components in our information libraries.
In the software/code area, some of the problems which have led to disuse of parts libraries are change in language focus. For example, in IBM the effort to make applications portable to our many platforms led to changing from PL-based languages to C or C++. The successful PL libraries were either ported or have a declining usage. Another problem area associated with languages is the ``good'' compiler ``lag''. By this I refer to the many Ada programs which were written and then re-compiled and re-tested many, many times as the compiler problems were gradually resolved. This type problem continues to occur, but to a lesser degree. However, the overhead of re-testing, and sometimes, modifying a large set of components for every compiler release led some (especially Ada) programmers to abandon reuse.
A newer generation of reuse problems is occuring for OO programmers as they try to reuse class libraries built by other product groups. This class of problem offers some interesting challenges for the next few years.