Risks with software reuse

Why should you care about risks with reuse? Because, these risks are real not made up and can make the difference between success and failure for your development effort. Here are a few risks that spring to mind:

  • Needless complexity
  • Inflexible design/will cost too much to modify
  • Domain irrelevance
  • Inadequate documentation/training/awareness
  • Ability to meet deadlines/dates (schedule risk)
  • Increased development, testing, and maintenance costs
  • Pursuit of technical elegance/architectural purity

These are not all the risks with reuse but the major ones that I have come across.

Now, what do you with these? You do what leaders do and that is address them head on. Instead of sulking about these you should plan and execute mitigation steps for these. Refactoring is the fundamental technique for addressing these risks! Take another look at the above list. You can use refactoring to handle most of these if not all of them.

  • Needless complexity – build only what you absolutely need with just enough abstraction. Refactor needless layers and abstractions. Keep things as simple as possible.
  • Inflexible design/will cost too much to modify – refactor your design to focus flexibility on the variations inherent in your problem domain. Not everything needs to be flexible!
  • Domain irrelevance – Build only what is relevant to your domain. If you are not sure, don’t commit prematurely.
  • Ability to meet deadlines/dates (schedule risk) – cannot take a reusable asset to the planned design target? Plan to pursue refactoring these in your future iterations
  • Increased development, testing, and maintenance costs – don’t build domain irrelevant reusable assets. Every asset you build should be for a real business need. Refactor the rest so as to leverage existing solutions – watch your costs go way down.
  • Pursuit of technical elegance/architectural purity – again, refactor imperfections over time. Think incremental and iterative.

I am not saying this will solve all your problems and address all the risks. But, it will get you on the right path. If you step back and focus on what is essential and what you know is likely to vary you can adjust your efforts accordingly.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

About these ads

2 Responses to Risks with software reuse

  1. [...] the capability add significant schedule or technical risks? If so, you need to make this transparent and get clarity from your sponsors. You can explain the [...]

  2. [...] complexity is a real risk with trying to pursue systematic reuse . In trying to get reuse, you don’t want developers to [...]

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

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: