

The Fallacy Of ReUse Sunday, June 7th, 2009. This industry is pre-occupied with reuse. There’s this belief that if we just reused more code, everything would be better. Some even go so far as saying that the whole point of object-orientation was reuse – it wasn’t, encapsulation was the big thing. After that component-orientation was the thing that was supposed to make reuse happen. Apparently that didn’t pan out so well either because here we are now pinning our reuseful hopes on service-orientation. Entire books of patterns have been written on how to achieve reuse with the orientation of the day.

Services have been classified every which way in trying to achieve this, from entity services and activity services, through process services and orchestration services. Composing services has been touted as the key to reusing, and creating reusable services. I might as well let you in on the dirty-little secret: Reuse is a fallacy Before running too far ahead, let’s go back to what the actual goal of reuse was: getting done faster. That’s it. It’s a fine goal to have. And here’s how reuse fits in to the picture: If we were to write all the code of a system, we’d write a certain amount of code.

If we could reuse some code from somewhere else that was written before, we could write less code.

The more code we can reuse, the less code we write.

The less code we write, the sooner we’ll be done! However, the above logical progression is based on another couple of fallacies: Fallacy: All code takes the same amount of time to write Fallacy: Writing code is the primary activity in getting a system done Anyone who’s actually written some code that’s gone into production knows this. There’s the time it takes us to understand what the system should do.

Multiply that by the time it takes the users to understand what the system should do

Then there’s the integrating that code with all the other code, databases, configuration, web services, etc.

Debugging. Deploying. Debugging. Rebugging. Meetings. Etc. Writing code is actually the least of our worries.

We actually spend less time writing code than… Rebugging code Also known as bug regressions. This is where we fix one piece of code, and in the process break another piece of code.

It’s not like we do it on purpose. It’s all those dependencies between the various bits of code.

The more dependencies there are, the more likely something’s gonna break.

Especially when we have all sorts of hidden dependencies,

like when other code uses stuff we put in the database without asking us what it means,

or, heaven forbid, changing it without telling us. These debugging/rebugging cycles can make stabilizing a system take a long time. So, how does reuse help/hinder with that? Here’s how: Dependencies multiply by reuse It’s to be expected. If you wrote the code all in one place, there are no dependencies. By reusing code, you’ve created a dependency. The more you reuse, the more dependencies you have. The more dependencies, the more rebugging. Of course, we need to keep in mind the difference between… Reuse & Use Your code uses the runtime API (JDK, .NET BCL, etc).

Likewise other frameworks like (N)Hibernate, Spring, WCF, etc. Reuse happens when you extend and override existing behaviors within other code.

This is most often done by inheritance in OO languages. Interestingly enough, by the above generally accepted definition, most web services “reuse” is actually really use. Let’s take a look at the characteristics of the code we’re using and reusing to see where we get the greatest value: The value of (re)use If we were to (re)use a piece of code in only one part of our system, it would be safe to say that we would get less value than if we could (re)use it in more places. For example, we could say that for many web applications, the web framework we use provides more value than a given encryption algorithm that we may use in only a few places. So, what characterizes the code we use in many places? Well, it’s very generic. Actually, the more generic a piece of code, the less likely it is that we’ll be changing something in it when fixing a bug in the system. That’s important. However, when looking at the kind of code we reuse, and the reasons around it, we tend to see very non-generic code – something that deals with the domain-specific behaviors of the system. Thus, the likelihood of a bug fix needing to touch that code is higher than in the generic/use-not-reuse case, often much higher. How it all fits together Goal: Getting done faster

Via: Spending less time debugging/rebugging/stabilizing

Via: Having less dependencies reasonably requiring a bug fix to touch the dependent side

Via: Not reusing non-generic code This doesn’t mean you shouldn’t use generic code / frameworks where applicable – absolutely, you should.

Just watch the number of kind of dependencies you introduce. Back to services So, if we follow the above advice with services, we wouldn’t want domain specific services reusing each other.

If we could get away with it, we probably wouldn’t even want them using each other either. As use and reuse go down, we can see that service autonomy goes up. And vice-versa.

Luckily, we have service interaction mechanisms from Event-Driven Architecture that enable use without breaking autonomy.

Autonomy is actually very similar to the principle of encapsulation that drove object-orientation in the first place.

Interesting, isn’t it? In summary We all want to get done faster. Way back when, someone told us reuse was the way to do that. They were wrong. Reuse may make sense in the most tightly coupled pieces of code you have, but not very much anywhere else. When designing services in your SOA, stay away from reuse, and minimize use (with EDA patterns). The next time someone pulls the “reuse excuse”, you’ll be ready. Further Reading Additional logic required for service autonomy

Self-contained events & SOA

Autonomous Services and Enterprise Entity Aggregation [MS Architecture Journal]

Does SOA mean the end of OO? [Podcast]

If you liked this article, you might also like articles in these categories:

Architecture | Autonomous Services | EDA | OO | Web Services

If you've got a minute, you might enjoy taking a look at some of my best articles.

I've gone through the hundreds of articles I've written over the past 6 years and put together a list of the best ones as ranked by my 5000+ readers.

You won't be disappointed.

If you'd like to get new articles sent to you when they're published, it's easy and free.

Subscribe right here.

Follow me on Twitter @UdiDahan.





Something on your mind? Got a question? I'd be thrilled to hear it.

Leave a comment below or email me, whatever works for you.



60 Comments Your comment...









Recommendations



Guest Authored Books



