A recent discussion on the Extreme Programming Yahoo Group explored the apparent conflict between making software reusable and the XP practice of not writing code until it is needed. Ron Jeffries and others shared insights about the costs and benefits of code reuse, as well as how and when to do it in an agile environment.
Brandon Olivares started the discussion. He had just put 30 hours into some code and felt that it had potential to be reused. He was feeling conflicted about whether or not he should generalize it so that other projects might be able to use it.
As far as I understand it, XP discourages assuming something is going to be needed until you actually get to that point where it is needed. Also according to my understanding, that includes abstracting code to be more general for reuse, until there is duplication, and then it can be refactored.
Software reuse has long been touted as a great time-saver. Perhaps developers on another project could benefit by reusing his code instead of having to reinvent it. Brandon asked the group members how they decided when to abstract and generalize code, so that other projects could make use of it.
Ron Jeffries was the first to respond, outlining some of the reasons why reuse across teams can be more difficult and expensive than it might seem at first.
I have to do work to package it that I wouldn't do for myself; I have to document it; I have to make it more bulletproof, removing issues that I just work around automatically; I have to support it and answer questions about it; I have to train people in how to use it.
If I do those things, it's expensive. If I don't, using my stuff is difficult for others and doesn't help them much.
All of this leads Ron to approach the topic this way:
I build the abstractions I need. If I need it again, in a slightly different context, I would improve the abstraction. But unless my project's purpose is to build stuff for other projects, I try not to waste any of my time and money building for other projects.
Another poster observed that reuse can be facilitated by all of the projects sharing a common build system, and a unified set of tests. In this way, a team that wants to reuse some code can generalize it to fit their needs, and the build and test system will help ensure that they haven't broken anything for other projects that use the code.
George Dinwiddie, Ralph E. Johnson, and others recommended generalizing upon second (or even later) use. Adam Sroka called this 'emergent reuse' and noted that this seemed more efficient than the 'design for reuse' approach. A poster named Tim explains it to his business people this way: "The first time you have to pay for it to be coded, the second time you have to pay for it to be reusable, the third time it's free."
George pointed out that the more difficult problem might be how to make other teams aware of potentially reusable code. The cost of the communication necessary for useful discovery can be significant. Jeff Langr suggested that having developers pairing across projects could be an effective way to address the discovery problem.
Scott Ambler joined the conversation, pointing out that open source is a form of reuse that has been very successful. He also noted that code libraries, development kits, and even mash-ups are examples of software reuse that works.
Adam followed with this observation:
It is important to distinguish when my team uses what my team previously used vs. someone else some other time. The latter generally requires more forethought... even for someone outside my team to be aware of it. There is a cost to that, and that cost better yield some business value
How do you decide when to reuse code? Leave a comment and share your opinions and experience.
Community comments
Which kind of code I reuse
by Lucas Oleiro,
Like in spring way
by Moch Nasrullah,
Reuse and coupling
by Ronald Miura,
Reuse and agility can go hand in hand
by Vijay Narayanan,
When is reuse feasible?
by Udayan Banerjee,
Refactoring and authority
by Dmitry Tsygankov,
Reuse should be cheap
by Vitaliy Fedorchenko,
Reuse as a Cultural Value
by Kelvin Meeks,
My preferred approach...
by Jim Leonardo,
Test coverage for reusing across team
by Vinay Dayananda,
Oranizational Setup vs Project Needs
by Jorge Boria,
Which kind of code I reuse
by Lucas Oleiro,
Your message is awaiting moderation. Thank you for participating in the discussion.
In Brazil we have known patterns for the Financial system ID with different validation algorithms for companies and individuals. We also need validators for the postal service... This is the kind of thing that should be build for reuse without regret of wasting time and effort...
Like in spring way
by Moch Nasrullah,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree that creating reusable code is (very) expensive, as explained in this article.
Example of successful reusable code are Spring Framework, Java API, and some thing like that.
To achieve that, it must be common code, well documented(javadoc), have reference documentation and some tutorial, just like Spring and Java.
Reuse and coupling
by Ronald Miura,
Your message is awaiting moderation. Thank you for participating in the discussion.
Another issue people often ignore is the fact that reuse leads to coupling. Many times we end up depending on some implementation details, which often break over time, when evolving the library. Even if you depend only on a contract or an interface, if for whatever reason you need to change this contract or interface, you must change every single piece of software that uses it.
That is, assuming you reuse code in binary form (jars, dlls, etc.), across different projects. The most widespread form of reuse, the 'cut-and-paste technique' doesn't have this problem. It's interesting, though, that cut-and-paste have such bad reputation :)
Reuse and agility can go hand in hand
by Vijay Narayanan,
Your message is awaiting moderation. Thank you for participating in the discussion.
In my experience agile development and systematic reuse can peacefully co-exist (if not thrive!). At work I basically tag components and services that are potentially reusable and continuously refactor them into a central build system based on maturity and readiness. I also actively pair people across teams to learn and discover existing reusable assets so all the participating teams benefit. I also post assets that are partially reusable on our wiki. Based on business priority we take review this and invest in additional refactoring to make it reusable for others. I conduct several lunch and learns as well encouraging developers and team leaders to learn and exchange ideas on reuse.
thanks
Vijay
softwarereuse.wordpress.com/
When is reuse feasible?
by Udayan Banerjee,
Your message is awaiting moderation. Thank you for participating in the discussion.
The key to reuse is to understand the difference between "what my team previously used vs. someone else some other time". The first is very much possible and the second is very difficult. I have elaborated this aspect in my post setandbma.wordpress.com/2009/03/26/when-is-reus...
Refactoring and authority
by Dmitry Tsygankov,
Your message is awaiting moderation. Thank you for participating in the discussion.
- The typically agile approach to code reuse is refactoring - that is, you see some code duplication, you remove it.
- When duplication is scattered across different projects, it can only be removed by a person who has the authority to commit changes to (at least) three different projects - that is, two real-world applications and one library.
- A person responsible for library design can always try and create a Very Smart Framework, but it has all the risks and drawbacks of so called "big design up front". I find that most people are reluctant to use the new functions somebody has written for them.
- Another approach is to provide people with the authority to change code across several projects. Personally, I like the approach described in one of the earlier articles on InfoQ: www.infoq.com/articles/scaling-lean-agile-featu.... But I have never had the opportunity to work in that kind of environment - it might turn out to be not so good as in theory.
Reuse should be cheap
by Vitaliy Fedorchenko,
Your message is awaiting moderation. Thank you for participating in the discussion.
Actually it's possible to reach some acceptable level of reusability even for 'first use' components. With such patterns like inversion of control and service locator it's possible to do that almost without overhead (in comparison to 'just writing the code for today').
Anyway, code reuse is just a part of more conceptual problem (software knowledge reuse), and it's a good question how to organize our technical knowledge in simple and reusable manner. I think that model driven development is a good answer to this question (you may be interested in my open-source project NReco where I've tried to organize effective first-time reuse).
Reuse as a Cultural Value
by Kelvin Meeks,
Your message is awaiting moderation. Thank you for participating in the discussion.
In recent years, I've experimented with a number of different approaches to improving the adoption success rate of introducing Agile concepts into client organizations - to include increasing the level of reuse.
My conclusion is that to make a significant increase in the success rate of reuse - there has to be a fundamental change in the organization's behavior reward system. Reuse needs to be affirmed as a valuable behavior - by correlating it to compensation - and metrics for promoting and achieving reuse need to be embedded into the performance review process.
Two examples of attempts to improve reuse in the government sector include the following:
The Component Organization and Registration Environment (CORE.gov):
Another potentially useful reuse communication mechanism that is domain-specific to the government transportation industry is the Transportation Research Board's (TRB) Research In Progress (RIP) Database: rip.trb.org/
These two examples are not perfect by any means - and are insufficient without a corresponding change in an organization's behavior reward reinforcement mechanisms.
Kelvin Meeks
intltechventures.blogspot.com
My preferred approach...
by Jim Leonardo,
Your message is awaiting moderation. Thank you for participating in the discussion.
Much of this article focuses on "build for reuse the first time". There's another approach out there that I prefer. It's the "three step" approach.
The first time you need it, you just build it.
The second time you need it, you build it with an eye towards reuse, but don't worry about getting it right for reuse.
The third time you need it, you build it fully for reuse. By now you should know what is common to the functionality vs. what's specific to a given app/implementation.
I've often found the things that I think I'll reuse, I don't. Subtle differences in requirements can make all the difference.
Test coverage for reusing across team
by Vinay Dayananda,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with the main discussion in the article about not writing reusable code until there is a need. But there is way by which we can have(manage) reusable code across project(only when there is a probability of code redundency or functional redundency) by having unit/integration test coverage. So whenever someone in the project uses code used as a utility, he/she has to write a test for that usage so that if someone changes the reused code(utility), then the test fails indicating that there is a break of a functionality that is using the utility.
Also the tests around the utility itself will serve as a documentation for the utility.
Oranizational Setup vs Project Needs
by Jorge Boria,
Your message is awaiting moderation. Thank you for participating in the discussion.
The MPS SW from Brazil has a process requiring the preparation for reuse. The best implementations I have seen clearly separate the project's needs from the organizational needs. Following the example, Ron would send his code with some suggestions to an organizational function that will in turn analyze the cost and ROI of developing it into a reusable component in the organizational library.