Art of Software Reuse
  • About
  • Introduction
  • Why Do Reuse Efforts Fail?
    • Common Pitfalls
    • Conway's Law
    • Care About Risks
    • Pursuing Perfection
    • Lack of Domain Focus
    • Entropy
  • Tenets
  • Success Factors
    • Revisit Assumptions
    • Communicate, Constantly
    • Collaborate
    • Review Code
    • Be Domain Driven
    • Target Quick Wins
    • Reduce Friction
    • Document
    • Build for Immediate Use
    • Address Support Needs
    • Managing Complexity
  • Practices
    • Minimise Jargon
    • Leverage Interception Points
    • Delay Commitment
    • Never Waste A Production Incident
    • Be Disciplined
    • Be Demand Driven
    • Continuous Alignment
    • Iterate, Iterate, Iterate
    • Build a Product Line
    • Understand Lack of Reuse
  • Design
    • Wrap Legacy APIs
    • Think Products, Not Applications
    • Identify Common Needs
    • Create Common Connectivity Components
    • Consistent APIs
    • Manage Domain Variations
    • Evolve Functionality Iteratively
    • Offer Reusable Assets with Multiple Interfaces
    • Leverage Services Across Functional Flows
    • Mediate Service Requests & Responses
    • Refactoring
    • Abstract Utility Functions
    • Reduce Technical Debt
    • Facilitate Extensibility
    • Encapsulate Variations Using Patterns
    • Understand Adoption Barriers
    • Ease Testability
    • Supportability
  • Tips
  • Resources
Powered by GitBook
On this page

Was this helpful?

  1. Success Factors

Communicate, Constantly

PreviousRevisit AssumptionsNextCollaborate

Last updated 5 years ago

Was this helpful?

Success with systematic reuse is part-technology, part-process, and part-communication. In fact, a LOT of communication. A critical factor influencing reuse effectiveness is the mindshare that you enjoy with the developer community. That community might be your immediate team or a department, or even the organization. Regardless of the scope, the following are relevant issues to think and plan for:

Awareness:are developers aware what reusable assets can and cannot do? Can they understand the overall strategy behind the reuse effort? are they aware of specific assets, role for reuse in the development process, and the benefits?

Client experiences:think about the good and bad experiences. Every interaction matters, so does every medium – whether through mailing lists, bug reports, or phone calls to the reuse team.

Reputation:how strong are reusable assets referred to during design and implementation tasks? can clients trust the reuse team’s deliverables?

Asset Quality:is the asset behaving the way it is supposed to? is it robust? does it allow for variability? Is it architecturally with other assets? How does the potential consumer know about the quality?

Documentation:are assets well ? Is the document written with the reader in mind? Does it make sense – e.g. is it logically organized for a developer to follow and leverage?

Team member Behaviors:do they care about like their own? Are they approachable by developers from various external teams? Ensure there is genuine empathy for business aligned projects – just like in the outside world – if you care enough and deliver, more reusable assets will be utilized in the future.

Emotional Connection:do reusable assets enhance learning and provide a sense of accomplishment for the developer/tech lead? whenever feasible.

Ease of use:how are assets set up? are they easily configurable? are bootstrap code generated for developers? Take care to highlight ease of integration and the multiple mechanisms to your audience.

consistent
documented
client projects
Co-create assets
variability