Common Pitfalls

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?

There are quite a few well researched reasons out there! In my experience here are reasons why reuse efforts fail:

• Lack of leadership and vision for making the effort work within the organization’s ownership and cultural context

• Lack of alignment with what your business sponsors are trying to accomplish

• Overly ambitious big bang approaches where lot of big upfront design efforts are spent

• Wasted efforts on what i call horizontal software assets instead of domain relevant vertical reusable assets

• Not spending time learning the variations in your domain and what needs to be manged in a flexible manner

• Inadequate attention to the needs of production support staff when a reusable asset gets used across projects

• Pursuit of perfection rather than staying pragmatic to meet immediate and near term needs

• Focus on the technical aspect of software reuse at the expense of everything else

• Inadequate effort spent on performance testing and capacity planning to accommodate for increased use

• Not enough emphasis on the quality of reusable assets – e.g. exception handling, simple interfaces are all key

• Time spent creating and maintaining a reusable library instead of influencing and persuading development teams

• Lack of awareness or communication about what reusable assets are available

• Inadequate guidance with leveraging exiting or building new reusable assets

• Developers like to build stuff and reuse is perceived to rob them of the opportunity to solve tough problems

• Development managers are nervous about making something reusable since it will add schedule risk

• Senior management isn’t convinced that reuse has potential to save the organization resources or help release high quality products to the market sooner

• Lack of clarity around reusable asset ownership. Not addressing tricky questions such as – who gets to own it after they get created? who will maintain them? who will support the software asset in production?

• Little to no metrics on what is reused, what kind of assets are needed, those that already exist etc.

This isn’t meant to be an exhaustive list but was meant to highlight a key point about succeeding with systematic reuse. Even if you forget everything about this list, I would like you to walk away with one idea which is that technical reasons are typically not why reuse initiatives fail.Technical excellence is a necessary but not sufficient condition for succeeding with systematic reuse. There are a whole host of other reasons why reuse typically fails. It is prudent to pay attention to George Santayana’s reminder that,”Those who cannot remember the past are condemned to repeat it.”

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.