Building Reusable Assets With Agile Practices

When you start building reusable assets there is considerable awkwardness with trying to align your reuse strategy with iteration goals. The real challenge is when you are not sure about refactoring existing assets. You will discover hidden couplings to implementation technology or platform, undocumented assumptions about how something will work, and all kinds of duplications sprinkled across your codebase. Soon, you will find yourself asking the questions such as – What can we reuse? Didn’t we just solve the same problem? Is this reusable as-is or needs to be refactored? It will get easier to align your assets to a product line with time and practice. Product lines tend to grow and your understanding of the business domain expands. Your ability to spot common needs and variations in these common needs also improves over time. You will deliver on your immediate goals and still be building towards the systematic reuse strategy.

You are doing right if

  • You whiteboard a design as a team and in a few hours identify new and existing reusable assets
  • You design identifies gaps in an existing asset that needs refactoring so the asset can be reused
  • Add items to your refactoring list as and when you identify a gap in an existing asset.
  • The team collaborates on aligning your systematic reuse strategy with your iteration goals.
  • You are able to recognize variations in your domain and apply that to your reusable asset design
  • You are decoupling connectivity components from business logic components
  • A family of message types are defined and used for integration with external systems
  • Design patterns are being leveraged to support essential variations in your domain

Warning signs

  • You are spending week after week in design and architecture. There are no signs of working code.
  • New design patterns and technologies are being introduced without reason (showcasing architectural complexity or technical brilliance don’t count!)
  • You don’t organize existing assets in any consistent manner forcing your team to recall capabilities every time they want to evaluate existing code for reuse.
  • Nothing in the business domain tends to vary and you have a tough time finding common patterns across user stories
  • The codebase is sprinkled with several design patterns that increase complexity without any domain alignment
  • You create only CRUD type interfaces assuming that will address all product line variations
  • Every asset in your codebase raises an ad-hoc set of error codes
  • You are modeling all the complexity in your domain and trying to cram choices instead of meeting iteration goals

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

About these ads

9 Responses to Building Reusable Assets With Agile Practices

  1. […] This post was Twitted by t_agile […]

  2. […] Building Reusable Assets With Agile Practices « Art of Software Reuse Any BPM implementation *should* be relatively agile; this general list of building reusable assets with agile practices make complete sense for BPM. Have to love the first warning sign: "You are spending week after week in design and architecture. There are no signs of working code." (tags: agile bpm software development design) […]

  3. […] Building Reusable Assets With Agile Practices « Art of Software Reuse Any BPM implementation *should* be relatively agile; this general list of building reusable assets with agile practices make complete sense for BPM. Have to love the first warning sign: "You are spending week after week in design and architecture. There are no signs of working code." (tags: agile bpm software development design) Posted by Sandy Kemsley on Tuesday, September 29, 2009, at 1:01 pm. Filed under BPM. Follow any responses to this post with its comments RSS feed. You can post a comment or trackback from your blog. […]

  4. Fareesa says:

    One of the really good website I have ever visited, very informative material posted. One can get the effective techniques of software reuse by reading it thoroughly. Each and every article shows the deep knowledge and experience of the author. I must appreciate the experience sharing courage of Vijay .I think IT professionals should share their valuable experience or finding with the others through blogs or website. It may help a lot, especially for the new comers in the IT world, to avoid some genuine mistakes by applying the knowledge of other during software development.

  5. The warning signs are quite good. I can definitely relate to the first point when there is no working code. IMO, the architecture should not be as simplistic as possible for the first project, enhancements and more functionality can be introduced at later stage.

  6. Building Reusable Assets With Agile Practices « Art of Software Reuse…

    Thank you for submitting this cool story – Trackback from PimpThisBlog.com…

  7. […] Agile Practices for Building Reusable Services I wrote earlier about using agile software reuse and the key ingredients that are beneficial when pursuing such a strategy. In this post, I want to […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: