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. Design

Think Products, Not Applications

PreviousWrap Legacy APIsNextIdentify Common Needs

Last updated 5 years ago

Was this helpful?

We are often used to thinking about changes, bug fixes, and enhancements to an application or system. To be more effective with software reuse start thinking like a product manager responsible for a set of related products. Think mass customization. This perspective offers several advantages specifically related to systematic software reuse:

  1. Products have vendors who have a charge back model to recover the cost of installation, setup/configuration, leasing, maintenance etc. Your reusable assets are no different.

  2. Products typically come in multiple flavors or offerings. Think basic, intermediate, and complete flavors that all share a set of identical features and offer unique flavor specific features. See .

  3. Products have clients or real customers. You need a mechanism to track feature usage, common patterns across the domain, frequently encountered errors/exceptions, etc. You need metrics for all of this and it ideally should be captured, managed, and reported on via some administrative interface. Without these metrics you cannot effectively understand and govern reusable assets.

  4. Products require support for multiple concurrent versions. Sometimes you have to offer migration paths from one version to another. Other times you have to plan for a customer to upgrade to a newer version gracefully. Data migration scripts have to be thought through and need to be very robust to ensure there are no losses in translation when upgrading to a newer version. This applies whether the asset is a library or a service.

  5. Products require training – better the documentation better the chances of effective usage. If your documentation is engaging, interactive, and works well for a targeted audience you have a winner in your hands. No documentation means no reuse – it is that simple.

  6. Products have a lifecycle – at some point you introduce them, convince customers to adopt them, they get mature, and eventually get retired. Features get added, become simpler, and mature over time. Things are typically done iteratively. Understand this and your reusable assets can be introduced and evolved within the context of business requirements and priorities.

  7. Products need better logging, trouble shooting, customer support, and maintenance cycles. They need a team that cares about the quality of what goes out the door. Poor quality products don’t sell -period.

  8. Products need some flavor of marketing – whether it is informal word of mouth or formal presentations, events, and educational materials for customers your product needs to be front and center of your audience. One of the key reasons systematic reuse efforts fail is due to lack of awareness. No marketing means no awareness. Your reusable assets don’t have a voice and entropy sets in.

If you manage your applications as a set of products you will notice commonalities, manage variations better, market them, plan for migrations and upgrades, and top notch after-sales customer service and education. In short, you will set yourself up for success with your systematic reuse efforts.As always, you don’t have to do this as a firm wide thing.Start within your team – these practices will help your team build higher quality reusable software that ultimately help your ability to serve your business stakeholders.

managing variations