Tips for Effective Software Reuse:

Anyone who has spent time building software in an organization will tell you that achieving software reuse is extremely challenging. Large scale, systematic reuse is even harder in an organization. As a developer with deadlines to meet and functionality to deliver it is challenging to keep reuse as a priority. If you are a team lead this situation is worse - now you have to meet sponsor needs, deliver functionality on time and within budget, and manage the development team. Reuse, what reuse?

Tip #1- Name software assets appropriately

Whether you are naming a method, a class, a component, a library, or a service - pause a minute to really think about the software's purpose and capabilities in order to assign a name. An appropriate name will help you when trying to mine for existing software assets to be reused. Additionally, the effort will be fruitful when you are trying to refactor existing software assets to be more reusable.

Whenever you come across a method like doEverything() or a service SendDataToXYZSystemService - take a minute to rename them appropriately. Too often, a bad name will cause that extra bit of research for you to evaluate a capability that exists in your applications. If the name is too obtuse, you might not recognize functionality that is already there and build a duplicate one.

It is a good idea to name software assets based on the business functionality or capability. If you are publishing order updates to another system, why not call the asset PublishOrderUpdates instead of SendDataToABCSystem? When you name an asset in a simple, clear, and accurate manner you will be surprised how often it will help you reuse it.

Tip #2 Conduct Code Reviews

Code reviews are one of the most effective ways to ensure that your reusable assets are being utilized appropriately. Often times in a rush to get the product out the door, developers might put in code not realizing functionality that already exists elsewhere. Because it takes time and discipline to review code it is a good idea to do this in small chunks. The key is consistency not so much quantity of code. You would want a quick way to refer to what reusable assets exist and marry that with changes to your code. I often find myself discovering ideas for new reusable assets while doing code reviews also. Over time you will start to see patterns and duplication across code fragments and application functionality which will help achieve synergies.

When you see opportunities to refactor or create reusable assets, do separate them from the rest of your application code. Physically separate the source code and version control it as an independent entity. As with everything else this needs to be done iteratively and isn’t a must have for the initial release of the product. As assets evolve and become reusable they can be refactored out into their own repository for you to manage them better. Key thing is when they do become reusable you move them out. Version them and evolve them outside the main code so it is easier to integrate on newer projects.

Tip #3 Never release a reusable software asset without a suite of automated regression tests

If you are going to bet on a reusable software asset and advertise it to the world you need to have a suite of regression tests for it. Why? Without regression tests, current and potential consumers will not have adequate confidence in the asset. The very foundation of reuse is to get a higher quality - less opportunity for errors, bugs, incorrect implementation of requirements - from not having to produce something that is already exists. To make sure you can deliver on this promise, a comprehensive suite of automated regression tests is a must. It will not only help you for your immediate consumer but for everyone thereafter.

Tip #4 Get requirements from production support for your reusable asset

There is one thing you should do before placing your reusable asset into production and that is talk to your production support staff. Get their input, share your design, and get their feedback early and often. This will not only make your asset supportable (imagine a reusable asset without logging or instrumentation or ability to report on key metrics) it will also get you a valuable partner. Production support will soon learn to trust your assets, your services, and will demand that multiple projects leverage the capability. It is one thing for you to sell reuse but another thing for your partners to voice.

Benefits of reuse:

•      Increased reliability

–      Components exercised in working systems

•      Reduced process risk

–      Less uncertainty in development costs

•      Effective use of specialists

–      Reuse components instead of people

•      Accelerated development

–      Avoid original development and hence speed-up production

Reuse problems:

•      Increased maintenance costs

•      Lack of tool support

•      “Not invented here” syndrome

•      Maintaining a component library

•      Finding and adapting reusable components

Key points:

•      Design with reuse involves designing software around good design and existing components

•      Advantages are lower costs, faster software development and lower risks.