Not sure if something is reusable? Delay the decision…

The really interesting problems in your domain will require considerable thought, collaboration with project stakeholders, multiple iterations, and real end user feedback. This is the prime real estate for systematic reuse to thrive. However, just because something seems reusable, it may not be…at least, not yet.

Consider these questions….

uncertain1Is a piece of functionality really reusable beyond the immediate project?
Will making something reusable add significant change to the existing design?
Is the relevant problem domain for the functionality being understood?
how will this functionality evolve over time?

When you have more questions than answers about a potential reusable asset – resist the urge to generalize, add layers of abstraction or product variability. Instead, focus on the immediate business requirement and fulfill just that for your immediate iteration or release. Mark the idea or functionality as a reuse candidate but don’t necessarily make it resuable yet precisely because you may not know what you don’t know.

Kevlin Henney, in an entry in the book, 97 Things Every Software Architect Should Know refers to the this concept calling for ‘Simplicity Before Generality, Use Before Reuse.’ (This book is a must-read by the way – a superb collection.)

Remember, the additional domain clarity over the life of the project combined with real user feedback will help not hurt your cause.

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

5 Responses to Not sure if something is reusable? Delay the decision…

  1. […] Domain irrelevance – Build only what is relevant to your domain. If you are not sure, don’t commit prematurely. […]

  2. […] be perfect from the get-go. Instead design for reuse iteratively. In earlier posts I blogged about delaying commitment and gave an example of an iterative way to build a reusable […]

  3. […] Iterative Design Agile practices espouse simple design and avoiding big design upfront (BDUF). Iterative design is to build a reusable asset in successive iterations. Too many systematic reuse initiatives have failed in pursuit of the perfectly reusable software component or service. Business requirements, motivations, and goals change continuously and trying to implement the perfect asset only makes design risky. Iterative design also is about building for your immediate requirement and nothing more. Have a very cool idea to extend an asset? Add it to your project lists of tasks or refactorings and align them with iterations as appropriate. Just design what you must. There are times when you know future requirements and you can build towards that but those are still predictions. When in doubt, go back to the basics: understand your domain, clarify existing domain models/relationships, refactor the design, and build towards reuse. Never hesitate to delay commitment. […]

  4. […] This is hard to get right the first time – often, business requirements aren’t clear from the early on making it tricky to identify reusable assets. More importantly, reuse adds project risk – specifically risk to the timeline. Always ask yourself if it is worth making the extra investment – if you aren’t sure delay commitment. […]

  5. […] is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment. […]

Leave a Reply to Risks with software reuse « Software Reuse in the Real World Cancel reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: