Systematic Reuse Panacea?

I received an email the other day from a professional asking if there was any new technology that I recommend for achieving immediate, widespread software reuse. The short answer is no 🙂

Technology is an important, essential, and necessary ingredient for systematic reuse. However, it isn’t sufficient to achieve widespread reuse. Hyperbole? No – widespread reuse is being touted from the days of mainframe routines, functions, object oriented design, and component based development to service oriented architecture and domain specific languages. Yes, the level of abstraction is inching closer to the business domain and the tools have certainly gotten richer and more reuse-friendly (for instance, refactoring support in IDEs).

So why hasn’t systematic reuse happened? There are equally relevant considerations with systematic reuse (ones that often get ignored):

  • Process – are your teams performing design and code reviews? how much thought is given to architecture – not only at a system level but when systems interact and exchange data? are requirements reused across projects? if not, are overlapping/similar requirements resulting in duplicate functionality?
  • Training- how can a new developer who joins the organization come to know about reusable assets? how do we reduce the learning curve and demonstrate utility of existing assets? how do we align architecture efforts to better leverage reusable assets?
  • Infrastructure – how are reusable assets identified, developed, managed, and retired? what if a team needs to contribute a patch to an existing asset? are there continuous/daily builds and automated tests for reusable assets? who ensures the quality of reusable assets? who “owns” these assets and how do they get supported?
  • Culture– do your teams collaborate and cross-pollinate ideas? is there a not-invented-here syndrome prevalent when it comes to leveraging existing solutions? how do technical leads and developers come to know about reusable assets?
  • Resource – how are resources allocated when they are meant to be useful for multiple applications? are there incentives for developing and leveraging reusable assets? are there resources allocated for horizontal components that are non-functional in nature – but extremely useful for several apps?

This is only scratching the surface and is meant to illustrate that technology alone isn’t a silver bullet to achieving systematic reuse. No single product or technology can guarantee reuse to happen organization-wide overnight. You can make it easier with the right set of technology tools/libraries/products but time, sustained effort, and calibrated strategy (one that takes into account your organization’s challenges and constraints) are essential for enduring success.

The Software Product Line (SPL) practices from Software Engineering Institute pursues a comprehensive set of practices that address the above considerations. It takes a holistic view of reuse covering multiple perspectives including people, process, technology, and places a common architecture at the heart of achieving widespread reuse. It isn’t promising a panacea and is a much better approach than buying a technology that is being touted to hand you reuse success.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: