Parts of the system could have been re-used, but the chance will be missed or unrecognized


Parts of the system could have been re-used, but the chance will be missed or unrecognized. 


The perennial problem with re-use is the recognition of the opportunity for re-use.  If one does not know what is available and could be re-used, the opportunity will be missed.  Is there COTS software that could be purchased and integrated?  Do we have a class of object already representing this entity that could be adapted to do both its current and this new job?  Is the data representing this object already in one of our databases in part or in full?  Do we have a design mechanism that already separates the concerns in the way we want them separating here?


In addition to this, there may be problems with re-use where the opportunity to re-use is recognized, but the existing code may be ossified; it may be a tangled, un-maintainable mess that one dare not touch.  Frequent minor changes have been applied while using the old saw “If it isn’t broken, don’t fix it” as a guide to keep changes to a minimum.  Restructuring the code to accept the changes in the optimum way has been disallowed owing to the risks of ‘unnecessary’ change.  This approach becomes a self-fulfilling prophecy; change becomes highly risky.

Prevention, Amelioration, Cure


Opportunities for re-use start with the domain concepts.  ModelTheDomain, and re-use this model for new systems in the domain.  Where areas have already been modeled, there are likely to be design classes and data representing these concepts in existing systems.  An enterprise framework can slot objects representing domain concepts into a re-usable architecture.  DesignPatterns are re-usable, and aid in keeping domain concepts pure by separating away design concerns.  Separation of concerns enables classification of resources by the type of concern they address; domain, architectural, design, communications, persistence, etc.  Teams can be organized to support better separation of core and application-specific assets by patterns such as OrganizationFollowsMarket.  It can be an advantage to have a shared project support activity to track COTS capabilities and feed information in to any ‘buy or build’ decisions.


Modern Agile methods typically prevent ossification of code from occurring.  ConstantRefactoring rejuvenates code, and one of its supporting techniques, CollectiveOwnership, ensures widespread knowledge of what is available.  The SimpleDesign technique of “Once And Only Once” specifically tries to ensure code is re-used rather than replicated.  A companion technique, YouArentGoingToNeedIt, keeps the volume of code to a minimum and thus gives more opportunity to be familiar with all there is.  DevelopingInPairs allows the inclusion as a member of each pair the person most likely to know what code is already available to address the current topic.  Although the efficiency of agile teams allows high productivity, it needs to be understood that large projects cannot expect to have knowledge of all the existing code resources brought to bear when producing each new fragment of code.