Strategic Reuse Process

Community managers have a tough job. They deal with lots of different stakeholders trying to find that elusive “middle ground”. They incessantly cheer on community activities and push adoption of collaboration best practices; but when it comes to validating their position through tangible and quantifiable metrics it can sometimes seem daunting. Is the best measure user participation? How about community size? Each of these seem like great things, and they are, but typically organizations don’t have a lot of tolerance for soft measures that don’t directly impact the “bottom-line”.

Recently I have been working to identify ways in which organizational performance gains can be tied to community activities. Since my current position involves helping large development organizations increase performance from their development organizations, I started first by looking at something that may seem far removed from community, knowledge reuse.

Why reuse, especially after my coworker, Guy Martin had several choice words to say about it yesterday? The reason I chose to build my case around reuse is that the potential for productivity gains is huge. Let’s do some simple math to illustrate the point. Let’s say a development organization has 1000 developers employed. The industry average indicates that a single developer will write somewhere in the neighborhood of 3200 lines of code per year. That’s 3.2 million lines of code! At an industry cost per line of code of $27 (taken from Applied Software Measurement by Caper Jones) that’s approximately $86 million in software development costs per year!! Wow! If we can replace just a fraction of that development effort with reusable components and establish a process for interweaving reusable assets into all software projects we can save an organization millions of dollars per year.

In this post let’s first look at the process of reuse and in later posts I’ll follow up with some specific suggestions for creating an effective reuse program.

Reuse Process

Reuse has five specific phases with hurdles between each phase that impedes progress to the next stage. Overcoming these obstacles will be key to the long-term success of your reuse efforts.

Reuse Process

Publication

During this phase knowledge is converted into something that is explicit and consumable by others. This phase represents the transfer of one person’s understanding, education, and wisdom into a tangible good. The publication format can be nearly anything – a blog, wiki, software artifact, anything that is consumable by another person.

Publication events are of very low value unless they can clear the first hurdle for reuse, Findability. Findability describes how readily available information is to other users in an enterprise. Enterprise strategies to increase findability include document repositories, index and search, push notifications, and categorization and taxonomy. Increasing the findability of assets requires a solid understanding of knowledge asset usage and user behavior.

Discovery

The Discovery phase begins when another user in the organization tries to find an answer to a problem relevant to them. During this phase the output of the publication event is found and analyzed for relevance against a new problem. This can be done via search, browsing, or by someone sharing a document via email. This is a particularly important phase because without discovery the publication event will go unused and is of very low value to the overall organization.

Understanding

During this phase information has been found but may not be fully understood by the consumer. This phase is a critical component of the Reuse Process because it promotes and encourages questioning and full understanding of the material.

Collaboration tools are essential during this phase of the process. The requisite for any collaboration tool is that a question and answer can take place to facilitate understanding between parties. To better disseminate information and to make it more accessible to others in the future, public exchanges should be used when possible. Communication channels like phone, IM, and email are great mechanisms that enable questioning and understanding but also limit the consumption of this “give and take” process to a very few parties. This sometimes is sought after behavior but in many cases the Reuse Process would be more effective if the discussions where held in public forums that are fully searchable and have meta-data such as comments and reviews that can be associated with the artifact.

Extension

The next phase of the Reuse Process is the Extension phase. In this phase we are applying the knowledge, wisdom, and education that was distilled in the original artifact into scenarios that we own and are a part of. In this way knowledge has been transferred to us from someone else and used in, perhaps, totally new ways. The context of the original information may only tangentially apply to these new scenarios, if at all. The idea being that because of someone’s published work we have been able to grow our personal knowledge base and now have the ability to extend a concept into a new area.

A great example of the extension of knowledge into new areas was the seminal work by Christopher Alexander “A Pattern Language: Towns, Buildings, Construction”. In this book Alexander makes the case for developing construction practices based on the fundamental notion that harmonious patterns have existed in architecture for centuries and that these patterns should be reused if they add value and harmony. This work was later applied to computer science by several researchers, most notably Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides and a new field in computer science was formed with the same basic tenets applied to computer science as Alexander had originally written about. This example clearly demonstrates the Extension principal (although on the extreme perhaps) that allows knowledge designed for one audience and context to be discovered, discussed, and transformed into another entirely different area of study.

Integration

The last phase is the Integration or Reintegration phase where changes that impact the original artifact are integrated back to improve the original. Integrations can take on several different forms from comments and ratings on a document to bug fixes or functionality enhancements for a software artifact.

The key to integration is to understand the need and desire of others to contribute and to provide the support and infrastructure that allows community and organizational knowledge to flow back into the original artifact.

Conclusion

Guy’s post yesterday points out that any process that adds procedural “red tape” will undoubtedly be circumvented in order to achieve results. I agree with that sentiment in most cases but also realize the value of process in others, reuse being one, and here’s why. As development teams organize more and more around driving value to the end customer via Agile methodologies, I see reuse as an area that could be overlooked easily without a unifying process. Project teams become focused on delivering their user stories and forget the bigger picture of component reuse because a) it was not budgeted for the sprint or b) no teams are working horizontally across the various project teams to discover reuse artifact candidates. But this post has gone on for long enough. I’ll post again soon and ferret out some of these issues.

Posted in DevOps/CI, TeamForge
One comment on “Strategic Reuse Process
  1. Guy Martin says:

    Brent,
    Fantastic post – and I agree with all of your assessments – my concern in my post was mainly that a lot of the ‘bottom-line’ types look at tools and metrics as an immediate solution to ‘the reuse problem’. Your post correctly points out that there is a whole lot more to it than that. Just having a ‘catalog’ and a ‘process’ doesn’t necessarily help increase reuse if there aren’t people on the front lines (developers) who are incentivized to reuse components.
    My post was driven by various things I’d heard lately around building ‘reuse catalogs’, and requirements for such catalogs making it clear that the *only* goal was to build a catalog so that a manager in the organization could stand up and say ‘Yep, built that beautiful reuse catalog – now everyone go use it’. My point was that a goal and system like that doesn’t lend itself to the community approach that you and I are both advocating.
    You make a great argument for the business side of the house, but experience with developers has taught me that mandating that something like a ‘catalog’ be used (without a community build around it for the developers to interact with) is a recipe for the developers doing the *bare minimum* to satisfy the mandate. Giving the developers a voice in helping to maintain reusable components goes a long way toward encouraging that reuse, and a lightweight process makes it more likely that they’ll actually do it.

1 Pings/Trackbacks for "Strategic Reuse Process"
  1. […] my last post entitled Strategic Reuse Process, we looked at an overall framework for analyzing how information flows through an organization and […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*