Resuable software assets need to be created and evolved with two perspectives – functional value and ease of integration. A library that offers little functional value and is difficult to integrate into an application is unlikely to get wide adoption.  Are there tips to balance these two perspectives? I think so and here are some pointers:

1. Minimize the number of 3rd party transitive dependencies – if reusing a module means bringing in 100 JARs, there are lots of opportunities for conflicting libraries build time and unanticipated runtime exceptions. I will elaborate specific strategies for this aspect in a separate post.
2. Carefully assess integration points in your environment – does your company already have a widely adopted library for concurrency, logging, alerting, or messaging? Then your reusable asset needs to facilitate or ease out of box integration. Most importantly, it shouldn’t attempt to provide the same capabilities
3. When providing overlapping capabilities you will have to convince the right set of folks that another API is necessary and there is a rationale for application teams to switch. Remember that the learning curve, integration effort, regression testing effort, and ongoing maintenance need to be factored into this decision
4. When you are not sure how an existing library in your organization works, descope integration and instead focus on the core value that is unique in your reusable asset. It is much simpler to bolt that on rather than invest in an integration mechanism that you cannot support well.
5. Boost developer productivity via IDE plugins, quick start project setup via Maven archetypes, or through code examples and automated tests. Regardless of what strategies you adopt the key is to demonstrate how easy it is to integrate your reusable asset with the rest of your enterprise.

Do these resonate with reuse practices you follow or have seen in your team? What other practices can help achieve adoption objectives?