5 Questions To Increase Systematic Reuse Effectiveness

May 13, 2013

Here are five questions to ask your teams to increase reuse effectiveness when evaluating a functional requirement:

  1. Is a requirement already met within the application or platform or is this the first time?
  2. If the capability already exists, does the current implementation provide the right extensibility? Often, existing code would need refactoring to meet a slightly varying set of requirements when compared to the original one. Take this as an opportunity to tease apart the abstractions necessary to capture the variations. What’s common and what’s truly different is the key aspect to figure out.
  3. Which other team or application has encountered this functional requirement before and how did they solve it? If you aren’t sure, ask around!
  4. Do we truly believe we are the first ones to stumble upon this need in the team/department/division/the firm? Try “laddering up” – as the Heath brothers call it in their latest book Decisive – incrementally and deliberately extract the key aspects of the problem you are trying to solve and look for places where solutions already exist. 
  5. If you find existing code to meet your need – evaluate it with a critical eye towards non-functional needs. Is it performant enough to meet the needs of your use case? does it provide adequate extension points / hooks to integrate with the rest of your application? is it a library or a hosted service? If hosted, what is the resiliency and availability strategy?

Too often, there is a bias towards implementing from the ground up due to either lack of time (don’t want to find out if other implementations or existing solutions exist and if they do, would they fit) or lack of trust (don’t want to use this team’s software or codebase or don’t trust that the quality of the implementation).

These aren’t exhaustive – what other questions come to mind?


Enabling Reusable Asset Co-Creation

October 25, 2010

In order to get critical mass for reusable assets, they have to be created and evolved in a collaborative manner across development teams. How can we enable co-creation? Several specific strategies can help:

  • Share the source – ever wondered why open source projects succeed when in-house efforts haven’t? Sharing the source code behind reusable assets makes a world of difference. It increases transparency (with respect to capability, behavior, and quality) and provides an opportunity for the developer community to participate in the analysis, design, and implementation activities. More importantly, it enables teams to modify the source per their specific needs and allows them to submit/merge the changes with the main build.
  • Provide detailed documentation for reusable assets that are both available, in-progress, and planned for the future. It can come very handy when there is a design decision to make in a project – time and time again, you will realize the greater the information on existing assets, the easier it becomes to enhance/change them and combine them in new and innovative ways.
  • Explicitly seek participation and design input when creating/updating a reusable asset. This not only increases buy-in from the tech community but also provides new ideas, concepts, and problem solving techniques that the entire department (even an organization) can benefit from.
  • Encourage questions, specially from new members and junior developers – welcome the most basic questions about the reusable asset inventory. Make sure an environment where open, honest exchange of ideas is taking place constantly. Good ideas come from several places and it is critical that developers don’t feel alienated or ignored due to lack of knowledge about one or more reusable assets.
  • Seek out subject matter experts – several developers and business analysts are essential to increase domain relevance, and domain alignment for reusable assets. Pretending to have all the answers or feigning perfection will only reduce the quality of reusable assets and ultimately prove detrimental to reuse objectives.

Several systematic software reuse efforts fail to get off the ground – it isn’t because of inadequate domain variations or severely limiting technology constraints – due to lack of grassroots appeal among the technical community.

Co-creation addresses several issues at once: it exposes developers to high quality coding practices, increases awareness of available assets, and provides a controlled environment to experiment and evolve reusable assets.


Silo Thinking Hurts Systematic Reuse

November 5, 2009

If you want to kill the potential for systematic reuse, all you have to do is think only about your silo and not about anything else. This silo could be many different things and in each case it inhibits reuse as well as the effectiveness of your team as a whole. Here are some specific examples:

  1. At the enterprise level, silo thinking can introduce very many inefficiencies and redundancies. Silo thinking will optimize solutions for a specific project at the expense of the overall firm. For example, say you have a reusable asset for calculating taxes and a new project re-implements the tax calculation business logic all over again. Or they ignore existing software infrastructure and introduce a new vendor product. This may help a specific project but adds cost and complexity to the enterprise.silos
  2. Silo thinking specific to an application means potentially reusable assets are not created and existing reusable assets are not leveraged. Think about the application’s needs to get reference data or connect with external systems or format data per a destination’s specific needs. Is your application using reusable assets? If not, is there an opportunity to create one by building or refactoring?
  3. Silo thinking specific to a team typically results in lack of reuse across projects that impact multiple teams. Do other teams in your department/division/organization know what reusable capabilities exist? do they know the overall reuse roadmap and how that aligns with business objectives? can they contribute towards growing the asset base?
  4. Silo thinking specific to a person typically results in solutions that don’t benefit other developers in the team. Maybe you have a neat utility that makes it easier to fetch correlated data across multiple data sources. Or you wrote a neat script that validates system variables or smoke tests key functionality. If they save you time and effort, why not share them with your team? Two immediate benefits will happen: other developers will start saving time as well increasing the team’s overall productivity. You will start getting constructive ideas on making these solutions better.

Have you noticed these? how do you encourage solutions that go beyond a specific silo’s needs?

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

tweet this add to del.icio.us post to facebook


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


Having Reuse-Friendly conversations

April 26, 2009

You approach a developer with an idea for a reusable software component or service. What do you typically hear as an answer? I typically hear variations of the same answers.  What do you when you hear these? Do you accept and give up? or attempt to persuade? if you are like me you want to persuade the developer. Here is a brief presentation on doing just that:

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! :


%d bloggers like this: