The need to change the developers attitudes towards reuse stems from the 'not invented here syndrome'. In the past the perception has been that the effort to understand, modify and incorporate someone else's code into your own was too great. Unfortunately the perception has too often been an accurate one.
The role of the reusability engineer is to work with the developers and ensure that they have at their fingertips the information they need to quickly and easily assess the suitability of any given reusable object. The phrase ``well- specified correct, robust and efficient'' [#!cline91!#] has become the key to turning developers attitudes around. Our experience has been that if they can understand easily what the initial requirements of an object were, then they can assess whether it matches their needs. Similarly a common regression test procedure allows the developer to determine an objects stability and to see if a particular test case is catered for and able to be handled by the object. If these two criteria are applied to all reusable objects, i.e. developers know what it is supposed to do and that it is done correctly, then they will happily reuse someone else's code.