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

Address Support Needs

How often you have worked on a project that didn’t consider support needs? I bet your quality of life as a developer was largely influenced by this factor. A supportable application makes a world of difference. Your reusable assets are no different in this regard. Reusable assets need to be robust against failure, scale up to handle additional volume gracefully, and provides relevant runtime metrics for diagnostics and troubleshooting. Here are some common requirements for support:

Handle errors appropriately– this could mean logging, notification alerts, integration with existing support tools, or even calling a particular person.

Instrument reusable assets– log error information, runtime data parameters, processing/transaction metrics, system variables and provide an interface to access all this stuff

Design for things to handle runtime failure– can you use an alternate path to fulfill a request? Can you store requests and process them after a time window? Even if you cannot do any of these, throw the error and report it. Never swallow exceptions

Report metrics– provide standard metrics reports as well as ability to perform ad-hoc queries.

Integrate errors with issue tracking when applicable– Link known errors happening in production with the relevant issue from the issue tracking system. Make it easy for the support person to know that it is a known issue, possible workarounds, and escalation paths.

Regardless of whether your team or an external group supports your applications, the support requirements need to be addressed. Without addressing supportability your reusable assets won’t be reliable, robust, or dependable.

PreviousBuild for Immediate UseNextManaging Complexity

Last updated 5 years ago

Was this helpful?