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

Iterate, Iterate, Iterate

PreviousContinuous AlignmentNextBuild a Product Line

Last updated 5 years ago

Was this helpful?

You want to make sure that you don’t spend an enormous time trying to build the perfect reusable asset. Be it a component, library, or service. Regardless of what you are trying to do accept that you won’t be perfect from the get-go. Instead design for reuse iteratively by (see to build a reusable asset).

Iterative design is needed to not only deliver incremental functionality over time but it is also a handy technique to address a key risk with systematic reuse – schedule risk. In a typical enterprise project there are a lot of moving parts – there are multiple stakeholders to satisfy, several teams including infrastructure, operations, production support staff to co-ordinate with, and ensure legacy systems and processes will not be negatively impacted. Given that most projects are delayed you don’t want a reusable asset to make matters worse. Designing for reuse is often mistaken for making software that is too generic or abstract. It becomes easy to slip into philosophical arguments about levels of abstractions and layers of indirection. It is tempting to lose sight of the business problem and pursue perfection for the sake of technical elegance.

Here are some warning signs that you need to watch out for:

  • Your developers are debating endlessly about a possible future use case that a component or service needs to support at the expense of what is currently known and required

  • More meetings are being setup to design the ‘right’ interface to make sure you are guarded against future changes to a service or component

  • You seem to be bogged down trying to figure out whether or not to support variation for a particular product feature.

  • Your developers are working on designing a business component that has no traceability with what your business user wants

  • There are endless discussions about whether or not a piece of functionality needs to be made reusable

When you smell this sort of behaviour, you want to pause, look back, and refocus on the deliverable at hand. Pursue iteration, not perfection.

delaying commitment
iterative steps