Building Reusable Assets With Agile Practices

September 25, 2009

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 Digg it : post to facebook: Stumble It! : :

Software Reuse Quick Tip #16

August 4, 2009

Tip #16 – Work with multiple stakeholders not just development

Systematic software reuse is a complex and challenging journey. Many of us in technology think of reuse from a developer standpoint. This is only part of the story. The success of reuse efforts often hinge on more than developers and development practices. You need to recognize the other stakeholders in this journey – they include system analysts, production support staff, information modelers, technical leads, and most importantly executives and development managers. Unless you have management support it will be tough influencing many projects in your organization. In the same vein, unless your reusable assets are supported in a production environment you cannot garner the required credibility of consumers and partners within your organization. Before you rush to buy the latest greatest silver technology silver bullet that will take you to the promised land of systematic reuse recognize that there isn’t one. It is a collaborative, incremental, and iterative effort requiring technical excellence, diplomacy and negotiation skills, and continuous communication. All these ideas apply whether your reusable asset is a library, framework, or service capabilities in a SOA context.

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

add to Digg it : post to facebook: Stumble It! : :

Systematic Reuse Success Factor #1 – Teamwork

April 18, 2009

Working alongside some very interesting and high performance teams I have come to believe that success with reuse is more than technical brilliance or elegant design.  Great teams produce high quality work, understand each other, their strengths, their limitations, and  most importantly harness conflict as a medium for healthy constructive dialogue, creativity, and innovation.

Peter Senge in his landmark book The Fifth Discipline says: “Almost all of us, in one time or another, have been part of a group of people working together in a extraordinary way. ..ever been part of a group who worked together in a extraordinary way, who were really exceptional in their effectiveness, in what they were able to achieve, and created a kind of environment that was really exciting to be part of.”brainstorm

Why is teamwork relevant to systematic reuse?

Because, producing something reusable under severe deadlines and delivery pressures, integrating with legacy systems and processes, working with a myriad teams spread across several organizational departments, geographies, and still delivering high quality products is incredibly hard. It is the kind of challenge that motivates technology leaders and professionals go to work and make a difference.

The fundamental technical concepts for systematic reuse are well understood and what differentiates the winners from the rest of the pack is their ability to execute the reuse vision within their business domains with the help of productive teams on the ground. Every single component, service, asset matters.

Extraordinary teams talk to each other often, exchange ideas and collaborate more effectively, and most of all identify and mitigate risks to ensure the team as a whole is best positioned for success. If this sounds a lot like the agile manifesto it is not coincidental! Building reusable services requires creative brainstorming, conflict resolution, design synthesis, and arriving at a logical point that will be used to deliver your iteration. This isn’t an event – its iterative, continuous, and execution focused.  If your team blends creativity and continuous delivery systematic reuse will be a natural byproduct.

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

add to Digg it : post to facebook: Stumble It! : :

%d bloggers like this: