You’re certainly entitled to your opinion, both on the topic at hand and my blog in general. In terms of confusion, well, to make an omelet, you’ve got to break some eggs – especially those that people have been using as a crutch. Sometimes, the questions are more important than the answers.

Thanks again for voicing your thoughts.

The majority of the posts are about how to use “reuse” and “use” where most people seem to use “reuse” where the author prefers “use”. That most posts discuss “use” vs. “reuse” appears to me as an indication that the article isn’t particularly good.

In my opinion way to “theoretical” with no real substance and doesn’t touch or addresses the problem around proper reuse (or should I say use so the author gets it?).

You hit the nail right on the head.

Reuse is very simple in the technical domain because components are not dependendent on the client’s requirements and therefore not subject to changes in those clients (an XML Parser implements an agreed upon standard that will only change in a very controlled way, and not very often).

A technical component can be autonomous in that it doesn’t depend on its clients.

A component implementing logic in a business (functional) domain will be dependent on its specific use by each of its specific clients.
A service providing customer information may have to accomodate clients from the marketing domain and from the accounting domain.
New clients and changing requirements in existing clients leads to the rebugging problem that Udi mentions.

The fallacy is the belief that this functional reuse problem can be solved by technical means (RPC/CORBA/WebServices/etc.), when it’s simply a problem of conceptual dependency between components of a system, regardless of their implementation.

Glad you liked it.

Fully agree with additional communication costs you mention.

I really liked this post.
I tend also to think about the myth of the reuse in terms of communication costs involved: sometimes just being able to know a that a piece of software does (something similar to) what we need is a cost. And this cost increases with team and project size. So, if the DRY principle makes perfectly sense within a well defined and manageable context, the cost of finding similarities in a large code base is probably higher than the benefits of reuse.

One thing I really liked is the fact that reuse increases coupling. There is an implicit cost in reusing components, and also in designing for reuse. Too often we tend to forget that.

Cheers

Alberto

Good point.

1. Your whole app is one method:

0 integration, Infinite complexity in the one method.

2. Your app is broken into minute components:

Near-zero complexity in each component, Near-infinite complexity in integration.

The DRY principle – don’t repeat yourself, is not just about specific lines of code, more important is to not duplicate semantics.

There are other ways of getting the necessary code to run without calling it directly (or via some interface) thus avoiding setting up an additional dependency. Moving the code to an extension point of some framework is one very effective way.

Does that make sense?

So it seems that we’re in agreement – there is more difficult (and therefore less common) good kind of use/reuse, and the easier/more common bad kind (abuse).

This post is in hopes of getting more people to stop and think which one they’re doing before justifying anything and everything with “reuse”.

Re, “There’s good reason to believe your conclusion is true, but you have not proven it” – my most expounded apologies

On “Reuse of code can only be attained when interfaces are closed”, I think we need to add some phrase to the tune of “the purported benefits of code reuse can only be attained…”

Will probably do a follow-up post.

Thanks for your comments.

Like you said, there’s good (re)use, and there’s bad, which can easily devolve into procedural programming.

As I understood, by “use” you mean using your service in several places, and by “reuse” — subclassing a base service class (reusing it) and overriding some members. Am I right?

How does it correlate with the DRY principle?

Thanks
ulu

Since we’re talking about fallacies, I suppose we should bring up the fallacy of equivocation.

http://en.wikipedia.org/wiki/Code_reuse

Of course, reusing code is still using code (using it /again/).

If you have code that hashes a string and you happen to need to use that same hashing algorithm in another application, you can hopefully reuse it. There may well be no need to extend it, especially if you had written it from the start to be reusable.

That’s what libraries and frameworks are for! Reuse! Write some code that solves a problem in a reusable way to save time in the many applications that need to solve that same problem.

Extending and overriding behavior is not reuse. It’s actually somewhat the opposite. Rather than reusing existing code you’re writing new code. You may be reusing design patterns or interfaces, but you’re still writing new code. It’s polymorphism, which is difficult for most people to get right, which explains why it so often leads to poor design and buggy code. If those design patterns or interfaces aren’t applicable to your current application then you probably will spend more time patching, hacking, and debugging then you would have writing from scratch. I call that /abuse/ and /misuse/.

These statements are fallacious as well. There’s good reason to believe your conclusion is true, but you have not proven it. My reasoning would go more along these lines: You, as a developer, are less likely to know the specific business process so well that you never code any bugs into it with respect to the business needs. Combine that with the fact that you write generic kinds of code all the time for your different applications, and it becomes more likely to make the generic code more robust, and the domain-specific code buggy. You may also need to make a distinction between business-process-buggy and language-syntax-buggy. I would hope that most professional programmers don’t make syntax mistakes (or use a component incorrectly, for example), but we all know that’s going to happen…even quite frequently.

Having said that, I pretty much fully agree with your post. I realized something similar the other day. In the system I’m working on right now, there’s a lot of gateway/repository use. There is no gateway/repository REuse, though, and that makes me question usefulness of those patterns altogether, at least within the specific context that we’re using them. After all, if one of the interfaces changes, we have to fix all of the various implementations of said interface, which is breaking the whole concept of a closed interface.

Perhaps that’s a non-terrible way of putting it:
Reuse of code can only be attained when interfaces are closed.

Might also need to add the line: … are closed, and that interface’s objects are used throughout the system.

Not sure if I like that last part. What do you think?

Mihai, I think you missed a few of the subtleties of his argument, and I don’t think the title of the argument (unless it’s changed since you wrote your last comment) is as powerful a statement as you seem to think.

We live in an imperfect world, and with a lot of complexity, more so on computing than in other aspects of our life. The best method we have to deal with this complexity is reuse. It brings about its own problems, and is often misused, but it’s the best we have.

I can see how bad reuse in SOA might be more prominent than in software development in general. After all, reuse in coarser grained APIs (I took the liberty of seeing services as APIs) is harder to achieve and the error of trying it erroneously is clearer. But the title of your article makes a much stronger claim, one with which I can’t agree. I would consider toning down the claim laid out in the title — I might see the value of the argument with a punchline like “Reuse in SOA is overrated”.

When you write your second project on the .NET framework, you reuse the framework. Don’t believe you’re doing anything else. Your whole argument should be more careful about the facets of reuse that you find problematic.

True, there is also the not-so-smart reuse, but that’s not enough to cross the word from our vocabulary when talking about software success stories. I have no doubt that the most successful software reuses a lot. And here I’m referring of course to the frameworks that emerge. Photoshop contains code that applies filters and performs other operations to images — that is code reuse. Polymorphism, Strategy, Adapter are all tools to enable code reuse. The generic sorting method I would have written if someone hadn’t already written for me represents code reuse.

Cohesive components with a clear statement = reusable code. Componetization goes hand in hand with good reuse. I’d rather reuse the already written inference engines out there than write one from scratch in the name of minimizing, what did you call it, “rebugging”?

I urge care in the interpretation of words.

I remember that ratio being bandied around too. The thing is, that that’s not what’s important.

The question is the organization’s commitment to support this code, version it, test it, etc over the lifetime of any and all systems that use it. What happens when a bug is discovered in that code? Are all systems that use it patched? Do we have management in place to know where the code is being used? What if the patch breaks backwards-compatibility? Are we going to support multiple streams in production at the same time?

There’s more going on than just not writing code.