Systematic Reuse Success Factor #11 – Code Reviews

July 14, 2010

Code reviews can be extremely effective driving systematic reuse. To be sure, there are multiple objectives with code reviews (e.g. adhering to naming standards, detect defect, write consistent comments, etc.). Additionally, they can help with reuse in the following ways:

  • Reviews happen prior to code being placed in production – they give you a chance to extract, build, or integrate reusable assets.
  • Code reviews often identify opportunities to refactor – refactoring to reuse. Have you ever had a review where someone said, “you know what, you should talk to Joe, since he is building a similar thing…” or “…we should use the existing service for implementing this story.”
  • Reviews help discover reusable assets – you might include classes and interfaces (not necessarily neatly demarcated) – in a component that can really be split up into two or more components. It may be appropriate to slice up the logic to ensure the existing component isn’t too monolithic
  • Reviews are very effective in preventing defects – with reusable assets, quality is everything and the act of reviewing them is critical to their stability and production-readiness. These can be extended to unit tests and documentation as well.
  • Reviews are a neat opportunity to communicate to at least a sub-set of the team what reusable assets exist and how they can be leveraged. Often times, when assets are mentioned as-is, they may not be that well received. Place them within the context of a real project, a real deliverable, and a tangible need – now the communication is much more effective.

As more developers pitch in and learn from each other, the reviews will become a critical part of how you develop and evolve reusable assets.

3 Comments | Reuse | Tagged: , , , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #10 – Build Assets For Immediate Use

April 11, 2010

When building a reusable asset it is natural to anticipate future needs and provide the flexibility for various client usage scenarios. Before you jump in and code every single feature – pause. There is a reason why agile practices recommend iterative design and discourage BDUF (big design up front).  With systematic reuse, it is more important to get aligned to multiple projects and applications rather than build the perfect asset. Obviously, if you have a window into your next iteration’s needs or another project’s requirements, you will want to accommodate them. By the same token, if you don’t have a good idea what the future is going to bring – don’t add code and bloat the codebase.

The good news with improving a reusable asset is that it will benefit not only your new client but also existing clients. With that in mind, strive to address the absolute must with a reusable asset. For example, if you are creating a new standardized service to provide customer data – consider the many aspects to vary and facilitate reuse. You can:

  1. Offer multiple flavors of the service’s data – a set of minimal fields, a “most common” list of fields, and a fully populated flavor that returns all data.
  2. Offer multiple versions of the different flavors – e.g a getClient_v1_0 and getClient_v1_1
  3. Vary the output format returning XML, JSON, serialized object, or even RSS feeds
  4. Provide localized data (formatting, replacing data per a geographic locale).
  5. Support a variety of transport interfaces – HTTP, JMS, FTP etc.

Given these options above, it is tempting to build that ultra-flexible reusable service meeting all the needs of today and tomorrow. However, projects have deadlines and business imperatives – it is critical that reusable assets don’t jeopardize business objectives. Build a sub-set of the above that is absolutely essential for your immediate deliverable. Be ruthless with code that is unused and unnecessary. Your project might only need to support XML response over HTTP – so build just that and nothing more. You can use design practices, patterns and refactoring techniques to decouple your code appropriately (e.g. separating business logic and formatting logic). This will position you for extending the codebase in the future.

1 Comment | agile, Reuse | Tagged: , , , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #9 – Consistent API

November 26, 2009

Have you noticed how some application interfaces are consistently named and exhibit consistent behavior across components and services? This can be a critical success factor for systematic reuse. Reusable components are not isolated islands of functionality. Instead, they are meant to be leveraged in a variety of applications and business processes. Consistent interfaces provide several benefits:

  • They reduce learning curve when a developer tries to understand and evaluate the asset for his/her need.
  • Reduces technical debt – consistent API reduces the need to refactor code and reduces regression testing efforts as well.
  • They increase the likelihood of predictable behavior across applications. This is critical for assets that get reused across business processes with an impact ultimately to end user experience (e.g. what if your customer can update address when opening accounts but won’t be able to do that when updating accounts?).
  • Eases integration and testing efforts. Consistent behavior can simplify testing reusable assets. If an asset behaves consistently whether it is invoked by a web application or a backend process, knowledge about test data and integration behavior is applicable across multiple projects
  • Makes documentation easier to follow: consistent interfaces can facilitate the use of templates for document generation as well where similar files/hyperlinks can be generated.

These aren’t the only benefits – feel free to suggest additional ones.

1 Comment | Reuse | Tagged: , , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #8 – Business Value

November 13, 2009

There are two critical risks with reusable components – they are needless complexity and domain irrelevance. Needless complexity results in more learning curve for developers to consume the asset and increased development and maintenance costs for the provider. Domain irrelevance results in assets that are of little business purpose and inhibits the ability to reuse capabilities across applications within a domain. Adding business value to a reusable asset should be your #1 priority above everything else. I will focus here on broad categorizations to illustrate this success factor:

Increasing Revenue: reusable assets should help reach new markets, create new products and services. Reusable assets need to be domain-specific for the most part and strive to map to business capabilities. Most importantly, strive to focus on what provides competitive advantage for your firm. Invest in reusable assets that no one else in the market can build because they lack the expertise or resources. Finally, reusable assets should help you drive time to market down. If it takes longer to integrate and test reusable assets than to develop from scratch, guess what your developers and tech leads are going to prefer?

Decreasing Costs: Reusable assets should help by saving you duplicate work. Likewise, reuse can help reduce maintenance costs – but only if the assets are relevant. If your products are for a domain that has no reusable assets, you won’t be able to save costs. Also, when you reuse, there is potential to consolidate vendor solutions, data feeds, and proprietary implementations as well. Do factor in less licensing and ongoing upgrade costs. Note: don’t underestimate the cost of integration – at least during the initial stages of your reuse efforts. There is additional training and integration cost that has to be accounted for, before cost savings can materialize.

Increasing Agility: You can also add value by focusing on increasing agility. This is critical to avoid big design up front (BDUF) and big investments. Instead of trying to build perfect assets, try to build assets that meet your needs. If reusable assets can help you evolve capabilities that can benefit multiple applications, business processes, and services that will aid organizational agility as well – e.g. you can provide vendor agnostic abstractions, provide simple interfaces to complex orchestrations, automate repetitive manual steps etc.

Increasing Productivity: Reusable assets can drive increases in productivity for both business users and developers. For business users, reuse can facilitate access to same or similar capability across applications and processes. For developers, reuse can reduce learning curve (when they are using something repeatedly) as well as manual steps involved in integrating certain assets together (assuming you have not only thought about assets in isolation but when how they work together as well).

Reusable assets have to provide value so there is incentive to create, maintain, and consume it over and over again. This is easier said than done but it will make a big difference to your business objectives.

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

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

Leave a Comment » | agile, Reuse | Tagged: , , , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #7 – Document

October 21, 2009

You have a shiny new reusable asset. You successfully refactored it and tested it as well. Now what? Take some time and document it. This will help you clarify the scope and purpose of the reusable asset. It could be a single document with all the reusable assets. Or if all your team is collocated even a flipchart would suffice to start with. This doesn’t have to be perfect from the get go.  Something lightweight that captures what the asset does and how to use it, limitations, and assumptions would be fine. If you have several external teams that you provide assets to, you can capture their application name and contact person.

It is less important what tools you use. All your documentation should be in one place. I document all the services and components using a Wiki and include the relevant set of bugs/changes for this asset from our issue tracking system JIRA. I find this convenient but I didn’t start with a Wiki. I put up a bunch of assets on a whiteboard and marked them ‘do not delete’. It hung out there for a few weeks over multiple iterations. As the list grew with new assets I moved it to the team Wiki. I use a simple template for everyone in the team to use and made minor tweaks to the basic set of fields we document based on the type of reusable asset. This keeps the documentation fairly consistent but still allows us to capture specific fields. I also tag each asset with client names so I can easily identify asset usage. The same idea can be extended to tag specific protocols, file formats, and authentication requirements so you can rapidly query things off the Wiki.

Here are the fields that I use to document our stuff on the Wiki:

  • Name: name of the reusable asset. Simple conventions used for library component, service, message
  • Version: major, minor, and patch version
  • Status: in production or in development
  • Description: brief description including any major assumptions and limitations
  • Where is it: the path to the asset in our source code control repository
  • Available interfaces: java interfaces, a WSDL document, or needs message queues.
  • Security: type of token to pass to invoke the functionality
  • input/output parameters: the path to either a language  API or xml schemas based on asset type
  • Code Samples for typical usage: source code accessing the asset’s functionality.
  • Error Handling: business and technical errors returned by the asset. Sometimes remediation steps are included as well.
  • Known Issues/Defects: this could be a bulleted list or integrated with your issue tracking system
  • Notes: Any other useful information about reusable asset you need to document

You are not “done, done” till your reusable assets are documented in a central location for all your team to access. Make this a habit every developer follows and it will soon become second nature. Now you are ready to integrate this asset with the rest of your codebase and even communicate about the new asset to folks external to your team.

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

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

4 Comments | Reuse | Tagged: , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #6 – Address Support Needs

October 19, 2009

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.

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

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

2 Comments | Design, Reuse | Tagged: , , , , , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #5 – Manage Domain Complexity

October 16, 2009

Your domain might be complex and rich in variations that need to be supported. Trying to capture all the complexity is neither pragmatic nor feasible given the constraints you might be under. Instead, focus on the essential complexity. In addition, it is unlikely that your business supports all the variations in your problem domain.  Fortunately most domain variations are expressed as user stories and you can look for patterns across iterations and releases to get a better understanding. Deciding the sub-set of complexity to manage is an art and you will need to continually collaborate with folks on your team on this.

I use a set of simple categories to look for areas that have essential domain complexity. This list is by no means comprehensive but it gives you a sense of what could drive complexity.complexity

  • Data capture: the system might have multiple user roles and the kind of data, the validations/rules that execute on them all vary
  • Geography: variations based on geographic regions/countries/states including differences in language, date/time formatting
  • Combination of product features (also called as bundling): variations to support different product flavors (for instance basic supports features X, Y, and Z, professional supports features X, Y, K, and premium supports A, X, Y, and K).
  • Entitlements: variations in access to different parts of a system and perform varying tasks. Related to user population and transaction behavior as well.
  • Transaction behavior: variations in transaction behavior in terms of monetary limits, approvals/validation rules, how business exceptions are handled
  • Channel (also called as distribution channel or sales channel): product availability, feature availability, security, customer support, frequency and kinds of marketing communications etc.

Next time you examine a user story place it in light of your domain categories. Is it a recurring pattern across iterations? If so, you should add it to your systematic reuse roadmap. Don’t panic if managing domain complexity doesn’t influence your design from day one. Nothing here is about embarking on a big upfront design effort to manage all this complexity. You should differentiate between awareness and action. Your increased awareness of your domain will help you align your systematic reuse efforts with business aspirations and iteration goals. Think of this as your refactoring guide that helps you make surgical changes to your codebase.

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

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

1 Comment | agile, Design, Reuse | Tagged: , , , , , , , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #4 – Domain Context

October 10, 2009

There isn’t one right way to build reusable software assets. Your business goals, technical environment, iteration and release plans all contribute to both the timing and nature of design decisions. Refactoring existing code to meet business goals is also context driven. Consider:

  1. What product features typically go together?building blocks
  2. Do certain features vary more than others across products?
  3. Is it possible to vary a product feature at runtime or design-time?

All these questions guide design. For instance, if the goal is to support variability at runtime you could support adding new parameters and changing existing ones without code changes or application restarts. As you work on design, keep your domain relevant variations at the back of mind!

Take an example of a widget shop that needs to market its widgets. The user story is to produce different marketing labels based on widget type. There could be several variations to support – frequency of changes to label information, number of words, language, data formatting, mixture of static and dynamic messages that make up a label etc.

Depending on the complexity of your domain, the features could vary simultaneously or in isolation. Consider some of these variations and their impact on design.

#1 Label contents are only static content – you could use a single LabelGenerator using a file configuration.

#2 Label contents are a mixture of static and dynamic content – LabelGenerator now needs two sub-components – a StaticContentGenerator and a DynamicContentGenerator.

#3 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. – In addition to the content generators you need an internationalization component that can support multiple languages

#4 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. Date and currency formatting varies based on country – All components of #3 plus a DateFormatter and CurrencyFormatter based on locale.

Next time you start a project, understand more about the drivers for change in your problem domain. Your domain and the associated context should drive reuse. The more you understand the drivers the easier it is to decide what and how your software assets need to be reusable.

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

5 Comments | agile, Design, Reuse | Tagged: , , , , , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #3 – Capture Domain Variations

October 4, 2009

Capturing necessary variations in the domain is extremely important to systematic reuse. Business domains are filled with variations that need to be identified and managed across your codebase. Product line variations are at the heart of effective software reuse. To identify variations in your domain you need go seek subject matter experts as well as end users in your shop. Work with them closely to understand the domain, the aspects that tend to vary often, and how these variations are manifested in user stories. From the customer’s point of view, these variations are a natural way of how their business functions. Invest time to make sure that you not only recognize variations as a whole but also identify the sub-set of variations that really matter.

Given the pragmatic nature of software reuse that is necessary, it is unrealistic to identify all variations in a problem domain. Your iterations will not happen and working software won’t get delivered unless you can include and adapt domain variations as part of your development practices. From a design perspective there are some questions that will help you. Every time you look at a user story you should ask yourself:

  1. What domain entities involved?
  2. Are there entities being encountered for the first time?
  3. Is this story requested in more than one product or application?
  4. What aspect of the domain varies in the story? Some common variations tend to reoccur – the kind of user who uses a feature, number of features being offered, differences in behavior for a feature or a group of features, how features are bundled together based on business criteria, interface metaphors and themes, and reporting/charting capabilities.
  5. Are there a set of user stories or aspects of user stories that appear together often?

Are there additional questions you can ask to capture domain variations?

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

3 Comments | agile, Design, Reuse | Tagged: , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #2 – Ease of Integration

July 18, 2009

An often overlooked aspect of systematic reuse is integration of reusable assets with applications, processes, and services. Most teams focus on building a large inventory of reusable assets – services, objects, frameworks, domain specific language libraries. While that is necessary it is not sufficient for succeeding with systematic reuse. One essential ingredient is ease of integration. What do i mean by that? Specifically:

  • Evaluating the requirement and making a determination whether an existing asset can fulfill the need (as-is or with modifications) or a new one needs to be developed.reachingout
  • Address risks with integrating with a reusable asset (meeting SLAs, solution complexity, etc.)
  • Sharing information on available interfaces (is there a java interface? a web service?)
  • Providing code samples and integration design patterns
  • Provide comprehensive list of error codes and error handling recommendations – if a service throws a particular error what should the consumer do? are there specific business errors or data validation errors that the consumer needs to be aware of?
  • Ensuring the consumer doesn’t starve the reusable asset’s resources. This is essential for services based reuse where multiple consumers are invoking the same service capability.
  • Assistance with testing the integration (provide test data, unit test code, as well as utilities to test response time/throughput)

You can build up a service catalog and magically hope to achieve high degree of reuse and you will most likely be disappointed. Bottom line – reach out to your consumer and help them succeed. Make it easier for them to evaluate, integrate, and test. Slowly but surely your teams will start coming to you as opposed to you trying to ‘sell’ them on the value of reuse!

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

3 Comments | Collaboration, General, Reuse | Tagged: , , , , , | Permalink
Posted by vijaynarayanan

« Previous Entries
Follow

Get every new post delivered to your Inbox.