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 predicament is only made worse - now you have to meet sponsor needs, deliver functionality on time and within budget, and manage the development team. Reuse, what reuse?
Going through several projects and being part of very productive teams I have come to realize that software reuse is a viable idea. That isn't to say it is easy and there are several ways to botch software reuse. Lack of leadership and vision for making the effort work within the organization's political and cultural context and non-alignment with what your business sponsors are trying to accomplish is a key factor. Some efforts fail because they are overly ambitious where lot of big upfront design efforts is spent trying to design things future-perfect. Still others fail due to lack of design flexibility, inadequate planning, and funding issues. Communication effectiveness and awareness of existing reusable software assets is also a critical factor.
The purpose of this article is to present a few tips on succeeding with systematic reuse based on my experience with various projects. This is by no means exhaustive but my intent is for developers and team leaders to appreciate the variety of strategies - technical and non-technical - that one has to undertake in order to succeed with systematic reuse.
Tip#1 - Focus on domain-specific software assets
Business assets are what makes your application or product line unique, your organization special, and ultimately differentiate you from the competition. The faster you can develop, release, and iteratively improve your domain relevant software assets the faster you will meet changing business needs and delight your customers. If you only focused on building reusable business assets chances are that it is relevant to your business deliverables and reusable for future projects.
Too often, developers in their zeal to create a technical masterpiece, focus on building reusable components and services for problems that either have solutions inside your firm or from the open-source community. Now, if you have to, you have to - but try to avoid building new code for which solutions already exist. Isn't that what software reuse all about?
Tip #2 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.
Good names are obviously tied to your problem domain but general guidelines still are valid - 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 #3 Not sure something is reusable? Delay commitment
The really interesting problems in your domain will require considerable thought, collaboration with project stakeholders, multiple iterations, and real end user feedback. This is the prime real estate for systematic reuse to thrive. However, just because something seems reusable, it may not be…at least, not yet. Consider these questions:
- Is a piece of functionality really reusable beyond the immediate project?
- Will making something reusable add significant change to the existing design?
- Is the relevant problem domain for the functionality being understood?
- How will this functionality evolve over time?
When you have more questions than answers about a potential reusable asset - resist the urge to generalize, add layers of abstraction or product variability. Instead, focus on the immediate business requirement and fulfill just that for your immediate iteration or release. Mark the idea or functionality as a reuse candidate but don't necessarily make it reusable yet precisely because you may not know what you don't know.
Kevlin Henney, in an entry in the book, '97 Things Every Software Architect Should Know', refers to this concept calling for 'Simplicity Before Generality, Use Before Reuse.' Remember, the additional domain clarity over the life of the project combined with real user feedback will help not hurt your cause.
Tip #4 Evolve Reusable Assets Iteratively
When you recognize the need for a reusable software asset it is key to map out a realization strategy. If you approach asset realization big bang you could end up creating a software asset that is irrelevant to your project's immediate needs and add significant schedule risk due to increased design, development, and testing time. Either way, you will spend a ton of precious resources.
Instead mitigate these risks by evolving the reusable asset over multiple iterations. Take the example of a reusable asset that sends notifications to your users. Let us name the asset Business Notifier. Instead of trying to build the 100 bells and whistles that this asset could have we come up with a simple plan to evolve it over several iterations.
Iteration #1 - notification via email for predefined business events
Iteration #2 - allow user to choose notifications out of the business events
Iteration #3 - let users define custom business rules to generate business events
Iteration #4 - send notifications on a web console or instant messaging applications
Iteration #5 - allow users to include their friends when receiving notifications.
Iteration #6 - integrate notifications with workflow for review by a support person
Obviously this is just an example and the features you put into a specific iteration are based on business requirements, priority, ease of implementation, and other considerations. You could for example reduce investment in an asset if it is no longer a priority or vice-versa. The takeaway is no matter what you want to build as a reusable asset plan its evolution over multiple iterations. You will reduce risks, stay flexible to your business requirements and needs, and build only assets that you want to invest in.
Tip #5 Being Consistent is more important than following an industry standard
When building software components and services for reuse across applications it is more important to strive for consistency rather than to comply with a standard. If a bulk of your applications use a particular reusable component you can always treat the existing interface as an adapter that in turns invokes an industry standard API behind the scenes. Note however I am not suggesting that you blindly build new code for which mature standards already exist.
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.
Tip #6 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 #7 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.
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.
Tip #8 Understand the business need before trying to persuade
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. Why? Because when you truly listen you might discover that your existing asset does meet the need perfectly as-is or it doesn’t meet the need at all. Maybe your reusable service needs to meet a certain performance metric. Or if the existing service is leveraged, it will increase schedule risk. Whatever.
The point is your existing asset’s relevance to the problem at hand. Listen, evaluate, and persuade (if applicable). In that order.
Tip # 9 Co-create reusable software assets as often as possible
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. I often hear that developers and development managers don’t want to reuse or develop a reusable capability because they don’t feel included in the realization of reusable assets. 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.
Tip #10 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 support.
Conclusion
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.