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….
Is 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.