Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

Reuse Myth - can you afford reusable code?

  • submit to reddit

In my Agile Business Conference present (“How much quality can we afford?”) I talked about the Reuse Myth, this is something always touch on when I deliver a training course but I’ve never taken time to write it down. Until now.

Lets take as our starting point Kevlin Henney’s observation that “there is no such thing as reusable code, only code that is reused.” Kevlin (given the opportunity!) goes on to examine what constitutes “reuse” over simple “use.” A good discussion itself but right now the I want to suggest that an awful lot of code which is “designed for reuse” is never actually re-used.

In effect that design effort is over engineering, waste in other words. One of the reasons developers want to “design for reuse” is not so much because the code will be reused but rather because they desire a set of properties (modularity, high cohesion, low coupling, etc.) which are desirable engineering properties but sound a bit abstract.

In other words, striving for “re-usability” is a developers way of striving for well engineered code. Unfortunately in striving for re-usability we loose focus which brings us to the second consideration.... cost of re-usability.

In Mythical Man Month (1974) Fred Brooks suggests that re-usable code costs three times as much to develop as single use code. I haven’t seen any better estimates so I tend to go with this one. (If anyone has any better estimates please send them over.)

Think about this. This means that you have to use your “reusable” code three times before you break even. And it means you only see a profit (saving) on the fourth reuse.

How much code which is build for reuse if reused four times?

I would suggest the answer to this question is: very little.

Consequently development teams which write a lot of reusable code are costing their organisations a lot of time and money. Waste.

Reusable code is not the solution to any of our IT problems. It is a supply side only solution and not a very good one at that. While it may reduce the amount of code that is written it reduces it by artificially constructing supply rather.

Thus, reuse, as a solution to software supply problems, is a myth.

This leave two questions we need to answer.

First: how are we to get those desirably engineering properties if we can’t/don’t push reuse?

The good news here is that Test Driven Development, i.e. writing code that can be automatically tested with other code we write, also has the effect of promoting modularity, high cohesion, low coupling, etc. Thus the answer to this question is: Make your code testable.

This approach will retain focus and deliver worthwhile benefits.

The second question: How should we manage reuse? After all, there are some genuine situations were reuse is the right answer.

Here there are two answers, a micro and a macro answer.

The micro answer, when your working in a development team is: look for emergent reuse.

Don’t plan for reuse but look for opportunities to reuse something that has gone before. When you see the opportunity take the previous work and enhance it just enough to reuse it in your case. This way you only pay the price for what you actually need when you need it.

If you later find the same code is useful again then repeat the process. Improve it just enough to use it a third time.

Remember: you have the tests from the earlier answer to make it safe to do this. Without the tests things get difficult.

Now you’ve reused your code three times, you’ve pay the price a bit every time, and you have the tests to show it still works. By now the code is going to be getting pretty close to generically reusable.

Still, maybe you go round this look a third or fourth time. It doesn’t matter is making one piece of code reusable costs more in the long run than it would have done if you did it the first time because... You haven’t spent money making a lot more code reusable that never needed it.

Telling the future is hard. It is difficult to know whether code will be reused or not, so default to Not and save the money. Occasionally you will be wrong and it will cost more, but overall you will be right and you will save money.

The macro answer: if this code really is widely reusable by many people then, go into business. Market this as a library, a plug in, an application what ever. Let the market decide the economics of reusability.

Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Dean Schulze replied on Fri, 2010/11/05 - 2:46pm

This is a good dose of candor, which is often missing when the subject of reuse arises.  I wonder how many developers and managers who talk about reuse know about Brooks estimate of a factor of 3 when it come to reuse.

 There's no reason to invoke reuse or TDD when it comes to code quality.  Just do a good job of design and coding the first time.  I don't know why so many developers find this hard.  I see so much code that should never have been checked in that I wonder if many developers have any standards at all.  Some of the code I've seen is so bad that it should never even have come off of the keyboard to begin with.

 You invoke TDD (aka Big Test Up Front) to assure code quality, but how much does TDD code cost?  How many projects that start out as TDD see the project through to the end as TDD, and how many drop the tests when the schedule or budget gets tight?

Let's have the same candor when we talk about TDD as when we talk about reuse.



dennis sellinger replied on Fri, 2010/11/05 - 4:06pm

Good post. This corresponds well with my experience. That is, reusable objects will emerge. When they are identified, they have to be extracted and packaged as reusable. Your point about macro-reuse is also right on. API writing is hard. Not all code is API and should not be treated as such. Typically we start by making everything private and adding public API (for internal use) only when it is justified. In addition, we generally seal all classes as we believe it is a bad idea to sub-class classes that are not designed for it. When it comes to a public API (for sale to our customers), we generally add an API layer or (less often) redesign our public interfaces. This only is done once the scope and functionality of the API has more or less stabilized.

Jose Maria Arranz replied on Sat, 2010/11/06 - 5:08am

"The micro answer, when your working in a development team is: look for emergent reuse."


Said this I don't agree with your vision of the cost of reusing. Of course reusing is costly in the short term, but in the long term it saves tons of money.

The copy and paste approach is with no doubt the cheapest approach in the short term, and you know how much expensive is in the long term, regardless the methodology of design being used.

Two reuses is enough and it pays the checks in the long run.


Nicolas Bousquet replied on Sat, 2010/11/06 - 7:18am

Do not agree.

What is the true reusable code ? The code that has been made from the beginning to be reusable.

The Java API is not just us all writting again and again the same thing, and one day Sun (or Oracle) comes with a true reusable code based on someone not reusable one implementation.

They do a new design from scratch, and by analysing what others have done for years. So basically, when you end up having used some algorythm 20 or 100 times, you don't have in fact a good reusable code.

No what is more likely is that you'll have between 3 to 10 differents versions of this same code, none of them really reusable and theses being copied 50, 100, 200 times in your source code. Just imagine you have a bug on this code... From time to time, one try to improve one version of this code, and introduce some "real" reusable code. But he don't have the time. Truth is that the reusable implementation will simply fail in some cases (aka regression bugs).

And if you do have juste one version of the code, because it not really API code, but has just been promoted "reusable", it will be full of special cases, difficult to maintain and likely to have bugs in it.

In fact, the day Oracle extends java API ,it will not be used 3 times, but more likely hundred of thousand ot time for an unsuccessfull API.

So the trick is to understand what is framework/API code for your projects/entreprises. Best case is to find a solid API that allready exist that fit your need. Even if you have to pay for it, you have nearly bug free code, good support and no maintenance on it.

Using code and making reusable code is not the same job. Using code you don't need so much testing, so much design and documentation is not usefull at all.

Your reusable code has to be well engineered, has to be tested extensively, has to be documented extensively.

And there is another property that emerge from this. Only framework code will become nearly bug free in the end. Simple code will be full of bug, full of the nearly the same code copied 100x time. Full of little "private" API each developper will introduce for it's needs. (So you need to force your developper to use the API code instead of their own prefered code).

Then, you should know what the agorythms you'll use everywhere and that could benefits from your own framework. Then build it. Make it as small, documented and tested as possible and be sure everybody know it and use it.

Reusable code cost likely more than 3X the time. But by making good usage of it, you'll use them maybe hundred of times and reduce maintenance.

The point is not to make a code reusable for the sake of it, but to use reusable code each time you can/should. And that maybe 90% of your application code...

How many time do you see nearly the same request parameter parsing code ? How many time do you see a DAO for each table with no real logic ? How many time do you just copy past code from one JSP to another?

Other factors does count :

- too complex design/framework and nobody understand how the damn thing work. And nobody will use it anyway. Think about J2EE6. How many people master it from end to end ?

- not enough design / API code and your sofware has far too much line of code. Developement and maintenance  cost explode has the line number increase. As your software grow it become more and more difficult to extends or debug.

- you can't do big redisgn of your software. it's simply too costly. You have to make it right the first or second time or just live with it. it's not when your code is used in 384 differents place that you'll be able to do a complete redesign. You'll never do it.

Roger Parkinson replied on Sun, 2010/11/07 - 1:55pm

The estimate of 3 times seems wrong. Don't forget MM was written a long time ago and our tools and techniques have moved on. I don't have format estimates but, taking into account the ease of writing reusable code and the reduced cost of maintenance and training in its use I would say using it a second time justifies the extra effort. Possibly using it just once is enough given that to make it reuseable you need to make a reasonable job of documenting it which helps with maintenance. This may depend on just what you bundle into the term 'reuseable'.

Manjuka Soysa replied on Sun, 2010/11/07 - 9:02pm in response to: Roger Parkinson

Exactly. I don't think there is even a 1.5 times extra effort in writing for re-use - probably just some extra thought before jumping in to do the code. And that effort keeps getting reduced as you gain more experience.

Having said that, there are many levels of re-use, and code-level re-use is the lowest level. Code re-use is very likely to be restricted to be within projects due to many un-related reasons (teams working independently, lack of documentation, etc). If those issues are handled properly, ROI is very easy to achieve even if 3 times extra effort is neded.

Developer Dude replied on Mon, 2010/11/08 - 12:25am

If I reuse the code 10 or 20 times, or I only have to fix a bug in one place instead of 20 places, then the cost of 3X is well worth it. I love it when a PM/client/customer asks for some feature, I make one change in one place, and the feature now shows up in 20 places in the application. Either they think I am a genius or really productive, or preferably both - when the real virtue is that I exercised a little prudence.

Like anything else, you can't put absolute rules on reuse v. no reusing code - it depends on the situation, but if I find myself copying and pasting code, or writing the same thing twice, I find it is usually worth the expense of going back and refactoring the code to be one piece of reusable code. I would guesstimate that about 80 to 90 percent of the code that I make reusable I actually do reuse more than 2 or 3 times.

OTOH, I see a lot of people copy/paste code and then I have to maintain this code because they were too lazy and short-sighted to spend a little extra time to make the code reusable.

We all use reusable code every day - the JDK, other frameworks, etc. - at some point someone said/thought, 'gee, I think this would be useful as a lib/API/framework' and we all benefit from that.

As for the cost, I don't think it always costs 3X; most of the time I notice the similarity in code, I refactor to put the common code in a base class and the different code in a subclass. That usually doesn't take long.

What takes a long time is when someone has create 5 different versions of the same class, with small variations in each. Now when there is a bug, or I need to add a feature, I need to go through and modify/test each of those five classes, and there is at least 5 times as much risk that there will be a new bug introduced. The code is often harder to understand because it has evolved to be different, and now I have to understand the same basic code in multiple variations, instead of one place. I cannot over-emphasize how much easier code is when there is only one copy of some logic to do one thing, instead of five or ten different variations.

So, it all comes down to the judgement of the coder. Unfortunately, in my experience, most devs are lazy, short-sighted, and just don't care about quality. They use 'YAGNI' or some variation of it to copy/paste code to get something done that somewhere down the line someone else will have to fix/maintain/extend - not because they actually have a philosophical objection to it. In my experience, over-engineering code (whether for reuse or other reasons) is rare, being lazy, copy/pasting code, creating a bunch of crap, is much much much more common.

I believe a discriminating use of the practice of reuse is part of our craft. It is rare that I regret having made code reusable - indeed, I can't think of any time off the top of my head where this was the case at all.

But by all means, keep writing articles about how this is the case to justify not doing it.

Paddy 3118 replied on Fri, 2011/02/25 - 2:44am

Re-use is allied to maintainability too!

Needs can change over the years and some practices make it more easy to modify what you have to meet those changing requirements rather than chucking stuff wholesale.


Emma Watson replied on Fri, 2012/03/30 - 5:01am

I thought about one thing while I was reading it though... Isn't being able to change or add functionality to an existing code base one kind of re-use? If you had to rewrite everything for every new release of your software, that would be pretty painful. So you reuse the old codebase, right?


Kookee Gacho replied on Mon, 2012/06/11 - 10:33pm

The basilisk is called "king" because it is reputed to have on its head a mitre- or crown-shaped crest. Stories of the basilisk show that it is not completely distinguished from the cockatrice.- Dr. Marla Ahlgrimm

Carla Brian replied on Fri, 2012/06/29 - 7:23pm

I do the same thing actually when I code. I reuse program and a little of enhancement will do if it is necessary. - James Stuckey

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.