Poly Bloody Hard Reuse

Inside a project, reuse of code is simple, and natural. Outside of a project, it's too dark to read? You notice some duplication, wham-wham-wham, you refactor it into a happy state. Integrate, and you're done.

However, reusing code across several projects brings a whole new set of problems. A very, very formidable set of new problems. Hence, AlistairCockburn votes to rename "inter-project reuse" to a less naive name: "PolyBloodyHardReuse".

Here are some common problems that come with attempting reuse across plural projects: Okay, so it's bloody hard. When is it worth the difficulty?

HardReuse I get. BloodyHardReuse I bloody well get. PolyBloodyHardReuse makes my parrot jacknife into the freshly rolled jet black macadam. Can someone please explain why my bird died?

It's pining for the fjords.

Poly == many. So: PolyBloodyHardReuse would mean that there's many different reasons why it's BloodyHard to Reuse.

It rhymes, give or take a couple syllables, with Polymorphism, a topic familiar to OO designers as "hard".

The phrase was coined by someone learning OO. He was commenting that "reuse" is a diabolically difficult topic, but the word "reuse" is so short that people think it should be easy. Comparing to topics like "polymorphism" and "dynamic binding", be said that it needed a much longer word, like "poly-bloody-hard-reuse". The phrase stuck, for the reasons that the others said (well, possibly not the "pining for the fjords" one). --AlistairCockburn

There is only one letter difference between reuse and refuse. -- AnonymousSkeptic

When the configuration management issues are easy to work around

This doesn't just mean because of tools. Take my development situation: we're building up libraries of reusable things by making things when we need them, and extending them when we need to. We have multiple projects, but we only work on one project at a time. So shared class S gets its start when we need to write it for project A. Later, when we're working on project B, we extend class S to do some new stuff. Configuration management is easy, since project A should just keep using the same version of S that it did when we left it, and project B should use the current version of S.

Then we go back to project A. We refactor the code in A to use the latest version of S at an opportune time -- typically, when we need one of the new features. Now the configuration is: A and B both use the latest S. If we extend S some more, then B just keeps using the version we left it with.

This would fall apart if, for example, we had one team working on project A and another team simultaneously working on project B, both of whom were extending S in different ways (or maybe just if those ways are incompatible). Then we'd have to treat things as one big project, in terms of code ownership and churn. But we don't have that problem, so multiple-project reuse isn't very painful for us.

To turn things around: working on only one project at a time can make multiple-project reuse easier. --GeorgePaci

The extreme correlation of this, of course, is that if you have shared code between multiple projects, developed in parallel, then you really pay attention to ContinuousIntegration. -- RobertWatkins.

I concur with this observation. Intra-app (or intra-project) reuse is far easier to obtain than inter-app reuse for some reason. --top

I suggest renaming this to IntraReuseEasier? or the like. The current name sounds like sexual violence against tropical birds.

It's supposed to sound unpleasant - that's the point. And since when was Norway tropical?

See also ReuseReleaseEquivalencePrinciple, CommonReusePrinciple, ExtremeReuse, OoIsNotAboutReuse, ReuseHasFailed

View edit of March 13, 2007 or FindPage with title or text search