Many systematic reuse initiatives don’t take off the ground because of the over-emphasis on investing in a new set of components. There is all the talk and promise of enhanced productivity, reduced cost, and swift time to market – however, as focus shifts to building a library of components, real delivery suffers and business applications don’t see any material improvements.
My advice: think about extending and integrating your existing codebases more before focusing on building out a reusable library.
In practical terms – refactor, not just for one project or iteration but for every project and every iteration. Continuously refactor and slowly move the code towards an integrated set of functional and technical capabilities. Every time another application needs similar functionality – refactor and remove the duplication. When you are exposing a public API to your application – refactor bits of logic that tightly couple technical infrastructure concerns with functional logic. With discipline, over a few iterations, you can move code around in your existing suite of applications to the point where it will be obvious what is reusable and what isn’t.
Don’t stop there. Ask your stakeholders about how your team needs to add value – what is truly unique, what is your secret sauce? Provide laser-like focus on the unique capabilities your application / systems need to deliver. For everything else, question your code from a financial lens thinking like a portfolio manager – what components to replace with open-source offerings? which components have potential to be truly reusable across multiple applications? which components need to be completely divested out of? Once you get a good idea of what to maintain, what to put more effort in, and what to get out of – you can be more proactive in aligning your refactoring and reuse initiatives with real business value. Remember – systematic reuse is a means to an end. The real goal is to enable innovative products/services/solutions and reduce needless costs for your firm.