Some time ago, I wanted to try an experiment. We have two different projects. Both projects have a lot of business entities in common: drugs, prescribers, health insurance providers, etc. The questions I wondered are:
- how similar are the entities on the two projects; and
- is there any good reason why they can’t be merged?
I quickly got discouraged from trying to find answers to those questions. I’m almost certainly editorializing when I say this, but it seemed like the push-back took the form of: “look, there might be a good reason why they’re different, so why do you want to waste a bunch of time looking into those questions?”
Sometimes, push-back has been grounded in some pretty important sources. One of my co-workers often talks about Evans’ idea of a Bounded Context. Evans makes this claim, in Domain-Driven Design:
Code reuse between BOUNDED CONTEXTS is a hazard to be avoided. Integration of functionality and data must go through a translation.
That’s a pretty significant claim. And, I’ll confess, it doesn’t sit well with me. (There’s a snarky side of me, too, that asks: if that’s true, then why does Eric have a Time and Money component for download ? surely those entities can’t be reused outside of a bounded context).
Now, on the topic of reuse, I am, in fact, pretty ambivalent (in that word’s truest sense: I have very strong feelings in opposition). I’ve seen a few different organizations attempt big reuse initiatives. At one previous employer, a lot of money was spent trying to kick off an organization that built reusable components (in a very “Big Design Upfront” kind of way), and very few such components were ever reused. Even the ones that were reused were often cloned and tweaked.
In fact, I think there are some pretty sobering statistics that suggest that something like 99% of all corporate reuse initiatives fail.
On the other hand, Capers Jones makes this claim, in Software Assessments, Benchmarks, and Best Practices:
Reusability has the best ROI of any technology [with respect to process improvement], but effective reuse is not a game for amateurs. If your quality control is not top notch, then you will be reusing garbage, and your costs will go up instead of down.
(I should point out that he also says that efforts to reuse only source code do not have especially good ROI).
I additionally look at the many, many open source libraries out there. I find it hard to understand a project that isn’t using:
- Apache commons (at least Collections, Lang, Logging, and probably IO); and
There are many open source projects that make it easy and viable to reuse code. So I ask myself the question: why can SourceForge and Jakarta accomplish something cross-industry that organizations cannot accomplish in their own development shops?
This paper has some thoughts on the matter, but it still talks about things in a pretty abstract manner. (What does it mean, for example, to “maintain a close feedback loop between middleware developers and application developers” in an organization like ours?)
One could additionally claim that open source libraries are talking about “frameworks”, rather than “business entities”. Perhaps, one could argue, reusing a framework is an entirely different concern than reusing business objects. Um, well. Okay.
Intelliware has a whole whack of components ? most are “framework-y” ? that have been used on multiple projects (the database migrator, our Tidy utilities, test tools, XML tools, etc.), but even those aren’t as formally packaged or well-documented as, say, a Jakarta component. But I’ll go so far as to say that because of some really big forms of reuse, recently, I’ve been able to deliver some products to customers in really fast time frames.
At the same time, I find myself creating certain business objects again and again and again: User, Person, Organization (the whole “Party” model from Fowler’s Analysis Patterns), either “User Group” or “Role”. I find myself building these things again and again with trivial variations. I genuinely believe there’s something wrong with that repeated effort.
But every time I talk about packaging up certain things into a reusable component, I find myself stuck in an argument about how reuse doesn’t really work.