Fog Creek Software
Discussion Board

Strategies for Fostering Code Reuse

Here's something I was thinking about the other day...

Developers A + B are working on a project. The work they do overlaps somewhat and invariably developer A creates a (set of) class(es) that developer B could use if only developer B was aware of them. (e.g. A writes a class to convert a Java Date into a proprietary format used by a legacy app).

Code reuse is a good thing, but often in the rush to implement it doesn't happen within a project (or on subsequent projects).

Tools like JavaDoc are pretty good, but they need the other developers to look at the JavaDoc and have an idea of what they're looking for - a more proactive solution is needed.

Some thoughts I had on what could be done:

- Email all development staff (including project managers) a description of you class(es), why it would be a good candidate for reuse, when to use it, etc. [may possibly be a bit too intrusive]

- Appoint somebody as a code librarian (possibly rotating who is appointed regularly), email them, they are responsible for evaluating reusability, etc. [sounds a bit too bureaucratic]

- Use wikis or some other internal presence to document reusable components. [requires developer proactivity]

Thoughts, ideas, experiences?

Walter Rumsby
Thursday, July 17, 2003

all attempts at enforcing strict processes will be met with distaste from the poor people who actually have to do it since it is seen as extra hassle.

In all the shops I've been in there was some guy (not necessarily old, just good) who people asked / chatted about their projects with.  The kind of person you bump into in the coffee room and end up chatting about some code issue.  These are the people who foster code reuse by being unofficial code librarians.  Always 'x over in y had that problem; ask them how they solved it'.  Unofficial, very effective.  So, does every shop have this kind of info-hub?

constructive comment
Thursday, July 17, 2003

It's a communication problem, so a solution may depend on how many people are involved.

If it's one project, perhaps you have a team lead who knows (has seen) all the code and will catch a reuse opportunity at design time, or if programmer B failed to see it before coding then at code inspection time.

There are two ways to reuse a component: it may be designed for reuse (it's self-contained, like your date example); or it's a big special-purpose class, which needs to be refactored to extract common functionality when you want to implement something similar-but-slightly-different. When I was first learning OOD/OOP, someone told me that a component isn't reusable until after it has been reused at least once.

If developers aren't proactive (creating reusable components, and wanting to reuse components) then what can you do ... encourage/teach each person individually according to their need: for example, during a code inspection "For this class, you could have reused the date class from developer A ... I think you should now change your code to reuse that component before we accept this, because [reasons for reusing] ... and next time, why not grep the JavaDoc for 'date' before you implement a new class like this."

Your 3rd "wiki or internal presence" suggestion: I liked to put components that are intended for reuse in a specific directory in the version control tree. That gives you a place to look for components that are intended for reuse ... its being present in the 'reused' section on the VCS also warns you to be careful about refactoring it in your project (if it's used in other projects then your refactoring it in your project may break it in other projects).

Your 2nd 'code librarian' suggestion: I've heard of such a job description existing when the team is larger than mine was, but it seems to me that the people responsible for 'evaluating reusability' are the developers involved.

Your 1st 'email a description' suggestion: surely you only need a description of the classes functionality ... "when to use it" then is "when you want this functionality", and "why it is a good candidate for reuse" is "because it's sufficiently self-contained and stable."

Christopher Wells
Thursday, July 17, 2003

The whole idea of "code re-use" is a chimera, and a false economy to boot.

What generally happens is, someone has the great idea that everyone should share their code, to avoid re-inventing the wheel.  So, the "common classes" get written and disseminated.

Time goes by, bugs are found, inefficiences uncovered, new features dreamt of - but the "common classes" are never changed, because of (pick one) deadline pressure, programmer apathy with such a boring task, or the fact that no one is around who knows how all that code works anymore.  "It's good enough", the PHB says, "so leave it alone, and fix all these product bugs instead."

So eventually, the "common classes" become so embarrasingly broken, slow, and out of date that there evolves a tacit agreement to stop using them.  Everyone codes their own versions - which are invariable much faster, simpler, more robust, etc. - and keeps them updated to their level of tolerance/anal retentiveness.

But horrors!  This means that some of the code is DUPLICATED!  Well, yeah.  My job is to convert Mountain Dew into software solutions - maximizing code re-use is not an end in and of itself.  Ten different FooBar classes are probably sturdier than one ancient, non-understood, rickety piece of junk probably written by the junior-most programmer (because he was the only one naive enough to think it was a good idea).

But that's just my opinion - I could be wrong.

Grumpy Old-Timer
Thursday, July 17, 2003


I agree with your points, but that is only one possible outcome.  There is always the case of 100 different tools all using their own version of MyStringClass, MyGrowableArrayClass, and MyHashTableClass, all with their own idiosyncratic behavior.  If you are trying to maintain all that junk you will quickly see the need for a standard toolset.  You may be used to some feature of one class in one tool you're writing, but it's pain in the ass to use it on another tool.

As usual the truth / best practice is always somewhere in between the extremes.

Thursday, July 17, 2003

I certainly hope they're not all reimplementing their string and array classes.  If so, take a bit of time and learn STL.  It looks overly complicated at first, but it's immensely useful and people all over the world are familiar with its idiosyncrasies (whereas they might not be familiar with MyWonkyStringClass).

Also check out the Boost Library.  Good reusable code there, too.

I disagree that ten implementations of the FooBar class are sturdier than one.  I'd expect them to be ten times as flaky, as one-tenth of the eyeballs have looked at it and found one-tenth of the bugs, and one-tenth of the people even care about fixing those bugs.

The problem is -- as everyone else pointed out -- one of communication.  I'll emphasize what everyone else has already mentioned.  Use a wiki.  Set up a reusable code directory in your source control.  Have team lunches once in a while.  Do code reviews.  Send out status emails to the group.  Do whatever you can to get people talking to each other.

Thursday, July 17, 2003

Well, I think his point is that no one will bother to change a common class for fear of breaking other people's code, so instead they just patch on top of it.  Pretty soon the common class is irrelevant.

I agree this can be a problem... but I see a design problem here.  The common classes must have clearly specified interfaces, which are SIMPLE.  If you develop "common" classes while writing other code, invariably the "common" code interface gets littered with certain details that prevent its reuse.  If you have a simple interface, when you are writing code, it is easier to decide whether you should reuse that code, or write your own code because of some specific behavior that you need but nobody else does.

Hard to explain without a specific example, but I can't overemphasize the joy of simple interfaces.  When I look at something with a complicated interface, I would sometimes rather just write my own stuff, because at least I know it will work.

Does anyone actually USE STL?  I am learning more about it, and to me it seems elegant and well-designed.  But I have actually never seen people using it!  People where I work tend to use C++ with the C library, never STL.  A lot of people have an aversion to STL, for some reason.  I wonder if that is because it is not trivial to learn, i.e. you can't just learn it by reading some HTML pages.  I know there are sometimes deal-breakers like the increased compilation time with templates, and not all compilers are good with templates.

Friday, July 18, 2003

In embedded development, there's often a binary size requirement that needs to be met when adding a new feature, and this has the unintended side-effect of encouraging code re-use.

So why not introduce a similiar specification that would encourage non-embedded developers to re-use code? Impose a max LOC count or a max number of new classes created for a new feature. Code reuse becomes part of the engineering effort ("crude, my feature is over my class budget, but wait, look, CBobsWidgets does exactly the same as my CJimsWoppets...") as the developer juggles design decision to meet all the parameters.

Of course, an obvious problem with this approach by itself is that it would probably lead to a lot of obfuscated one-line code or monster classes ("crude, I'm over budget, well I'll just throw all my functionality into CJimsMonsterClass and beat the system") It would need to be tempered with something else to keep that from happening... a cap on line length or class size, good programming judgement, peer feedback, managerial thumping?
I Dunno... thoughts?

Friday, July 18, 2003

*  Recent Topics

*  Fog Creek Home