Systematic Reuse Success Factor #13 – Constantly Revisit Assumptions

June 16, 2013

It is natural to get comfortable, perhaps too comfortable, with the state of your codebase. After all, it works and is probably meeting tangible business needs. However, if your team has to get the full value out of it – the fair and ongoing return on investment – you have to constantly revisit assumptions about the software design and implementation.

Challenging assumptions has a number of benefits for systematic reuse. It opens up opportunities for refactoring assumptions that are no longer relevant / required (e.g. state information has to be saved for recovery). What if that capability is available in your enterprise through another component? Can you swap your implementation? If not, why not?

Similar opportunities exist on both technical and functional sides – the software is always accessed from the app’s web UI (assumption that might have led to code tightly coupled with presentation logic – business rules implemented alongside HTTP header parsing logic). How about assumptions regarding public APIs, nature/sequence of method invocations, client / calling platform, etc.

These assumptions must have made sense and would have been made for a sound reason at the time the codebase was conceived. Question is – are they still relevant? does the code need refactoring to get rid of native implementations or needs to be decoupled from logic that will make it more reusable? All these questions need careful and thoughtful consideration. 

Have this discussion as part of your iteration retrospectives, team discussions, and informal conversations. You’ll be surprised about the quantity and quality of assumptions that are holding the codebase back.

Systematic Reuse Success Factor #12 – Empower Tech Architects

August 26, 2012

They key word in the phrase “systematic software reuse” is “systematic” – that is what distinguished ad-hoc reuse from continuous, iterative, investment-oriented reuse that provides benefits across projects. Anyone that has driven change within an organization will attest that one of the key enabling factors is political will and top-management sponsorship. Similarly, systematic reuse efforts need intervention and influence across every project – it needs your architects to have a say in the design and the implementation. Technical architects cannot be passive and standing back whining and complaining that the development teams aren’t listening and they aren’t reusing existing assets or investing in creating new ones. In addition to hiring competent architects, management needs to empower them. They need to be given authority and made accountable for systematic reuse efforts – want architecture convergence? faster time to market? lesser cost of maintenance? All of these are possible with systematic reuse but only with proper investment and ongoing guidance and care.

Empowered architects should be able to alter/change the technical strategy, design, and implementation approaches to ensure that it is inline with the overarching technical strategy for reusing capabilities within the teams. Of course, this doesn’t mean they stop everything without delivering value to clients on a continuous basis. On the contrary, architects need to be focused on both alignment with reuse and business delivery. They need commitment from teams that pursue tactical measures that they will get out of technical debt and align completely with the technical strategy.  They should and be able to intervene throughout the development process – during requirements analysis, design, implementation and review by working with the development teams in a hands-on fashion. If the architect carries no decision making authority to stop releases, change approaches, or extract commitments – the technical debt will stay where it is and reuse will be an elusive goal.

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.

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.

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.

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 post to facebook

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 post to facebook

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 post to facebook

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 post to facebook

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

%d bloggers like this: