Reusable ideas about the reuse of software - Audun Fauchald Strand & Trond Arve Wasskog

Reuse should be discovered organically rather than being designed upfront and forced upon teams

Product mindset is critical - focus on making components attractive and useful rather than mandating their use

Social and technical aspects both matter - ownership, maintenance, documentation and team structures are as important as the technical implementation

Different reuse patterns have different tradeoffs:

• Shared libraries work well for infrastructure concerns
• Shared services require clear ownership and boundaries
• Platform approaches need product thinking
• Copy-paste can be valid for rapid iteration

Conway’s Law heavily influences reuse - how teams are organized impacts how software can be effectively shared

Scope and context matter - what works for small components may not work for large domain-specific applications

Open source has been transformative for infrastructure reuse but domain-specific business logic remains challenging to share

Common pitfalls:

• Over-generalizing components
• Underestimating maintenance costs
• Lacking clear ownership
• Forcing reuse through mandates
• Premature abstraction

Successful reuse requires:

• Clear boundaries between components
• Documentation and examples
• Active maintenance and support
• Team buy-in and organic adoption
• Understanding of actual vs perceived commonality

Focus on making reusable components that remove cognitive load and raise the level of abstraction for teams