having reuse friendly conversations
DESCRIPTION
Common reasons why developers resist reusable software assets and how to have productive conversations to harness their feedback.TRANSCRIPT
Having Reuse-Friendly Conversations
• Vijay Narayanan
• http://softwarereuse.wordpress.com/
Common Developer Responses About Reusable Software Assets
Needless complexity
Don’t like the interface
Doubting Thomas We tried it already
You left me out Too Late to include in the build
You have a critical choice when you hear these responses. You can either accept them or influence.
Influence by having reuse-friendly conversations!
Needless Complexity
• Probe for underlying concern…
• Is there an alternate design that can be considered? If you hear a simpler design be prepared to fuse it with the existing asset
• Is the reusable asset doing too much? Should some logic be removed? Trim the fat!
• Does the complexity not reflect the problem domain? If not, again offer to refactor it to the appropriate level of granularity.
Don’t like the interface
• This could be about several things:
• The interface could be incomplete (e.g. more methods or operations needed)
• The interface could be too fine grained and the developer is concerned about too many calls over the network.
• The interface is too generic and the developer thinks it is going to make it harder to read/write code.
• Or they might hate language specific APIs and they really want a service interface.
• The interface could be conflicting with existing class or method names. Don’t laugh, it happens!
Doubting Thomas• Developer might have a tough time you could actually do
what the asset claims to do
• It may be a trust issue as well – you need to show them metrics, instrumentation, logs, error handling logic, recovery, performance, and reliability. They want you to convince them that the reusable asset will be bullet proof and you have thought through issues from several angles
• If you can get them to help you address the doubts. Establish partnerships, have conversations. Come clean if you don’t have all the data that they are looking for and you need their help.
• Realize some folks will never be convinced no matter how hard you try. Just roll with the punches- its nothing personal. They would have a similar reaction with anything that is new.
We tried it already• Ask them what specifically was tried before?
Was the reusable asset designed before doing something similar? Different?
• Why did the previous effort fail? Was the abstraction wrong? Not aligned with the domain? Didn’t capture essential complexity?
• If the new asset is different – explain to them the differences and ask them for help to make this new design successful.
You left me out • Apologize (even if it isn’t your fault!) that you left
them out in the initial design. Communicate that the reusable asset is a work in progress not a finished product.
• They might have attempted to solve the problem before. Ask them for feedback on the reusable asset.
• If you have time incorporate their suggestions. If not, add it to your list of tasks for a future iteration
• You can enlist their help with code reviews, design reviews, and voting on what changes go when.
• Be sure to include them in the future!
Too Late to include in the build!• Assure them that the asset is a work in
progress not a finished product. So it can always be included in the future
•Use the opportunity to get their feedback on the proposed reusable asset
• Be sure to discuss the asset as part of your iteration planning. Get it on the product roadmap and add relevant tasks so this doesn’t drop off your team’s radar.
Conflict and constructive feedback are extremely
valuable to succeeding with systematic reuse.
Encourage reuse-friendly conversations!