What makes software reusable

This is specifically related to horizontal business capabilities that you want to reuse. For instance, say you need the ability to process credit card payments from several applications and there wasn't an industry standard at the time you needed this functionality. It is important to have a payment API that your apps utilize rather than wait for a standard to magically appear.

Day two, if and when a standard appears you can change the existing implementation without any impact to your existing applications. Okay maybe I am oversimplifying - you might need minor code changes and regression testing. But the bottom line is that you will be in a significantly better position rather than having to change code across your codebase. 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 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. 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. 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. You can create reusable scripts for compiling, executing, and reporting all your unit and regression tests. This is applicable whether you are building components or services or even business process flows.

The next logical thing to do would be to integrate these scripts with a continuous integration suite. It is often tempting to persuade a developer or a development manager so they agree to reuse a software asset.

However, if you repeatedly persuade without understanding the need, the business requirement it is unlikely that your efforts will bear fruit.

Instead of persuasion, try listening, empathizing, and truly understanding the requirement. Figure this part out and then identify the asset can be leveraged or developed. Maybe your reusable service needs to meet a certain performance metric. Or if the existing service is leveraged, it will increase schedule risk. Listen, evaluate, and persuade if applicable. In that order.

There are a variety of reasons systematic reuse initiatives fail including technical and organizational reasons. If there is no buy-in from development groups that are prospective users of these reusable assets it will not be possible for your initiatives to succeed.

How to deal with this factor? Instead of trying to convince, co-create reusable assets. If you get a requirement to build an email alert notification need - work with the original development team and involve them in the design. Better would be to get them to develop a portion or all of the capability.

If they co-created it with you, they will not think of the asset as a black box that they are being forced to use. You will be surprised with this - they will start helping you foster reuse by sharing this with their partners in the organization. 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 support. Using a mixture of technical practices, collaboration, and pragmatism it is possible to slowly grow your reusable asset base.

This article presented tips that I have used repeatedly as part of my everyday work in order to increase the odds of success. I am interested in hearing more about your experience with what has and hasn't worked when trying to foster effective software reuse. Join a community of over , senior developers. View an example. You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.

Your message is awaiting moderation. Thank you for participating in the discussion. Components are more abstract than object classes and can be considered to be stand-alone service providers. They can exist as stand-alone entities. They are moderately large entities that can be used. Application frameworks are somewhere between system and component reuse. We collect abstract and concrete classes that are adapted and extended to create application systems.

Systems are developed by linking shared services, which may be externally provided. A software product line is a set of applications with a common architecture and shared components so that they can be adapted for different customers. We can implement a number of adaptations as follows.

Systems are developed by configuring and integrating existing application systems without changing the source code of the system. They are adapted by using built-in configuration mechanisms that allow the functionality of the system to be tailored to specific customer needs.

Large-scale systems that encapsulate generic business functionality and rules are configured for an organization. Common business processes such as ordering and invoicing, manufacturing, etc. Generic systems are designed so that they can be configured to the needs of specific system customers.

Class and function libraries that implement commonly used abstractions are available for reuse. Software is represented as domain models and implementation independent models and code is generated from these models. A generator system embeds knowledge of a type of application and is used to generate systems in that domain from a user-supplied system model. Shared components are woven into an application at different places when the program is compiled.

Easy, right? Yes, enterprises must respond quickly to shifting trends and user needs in order to differentiate themselves and stay ahead of the competition. Reusing software components can help. Software reuse is the process of creating new software from pre-existing software components. A component is a part of a larger whole. Technology as a whole has gotten more complex in recent years, which in turn makes software development more expensive, time-consuming, and error-prone.

Plus, the diversity of platforms and architectures —and the need for tech teams to develop applications faster than ever before—makes it hard to build brand new applications from scratch every time. Software reuse emerged as a way to solve this problem and help Creators spend their development time more wisely for faster and more consistent builds. You can reuse software specifications, test cases, prototypes, frameworks, and much more depending on your specific needs and goals.

When you build an application using reusable components, you dramatically reduce your development time.