Summary
Every Java project is designed for reusability. Yet when time comes to do a new project in the same domain we always opt for building from scratch. Is software reusability, especially in the J2EE realm, just a myth?
Advertisement
My car broke in the middle of nowhere-ville near LA, and
I had to pull into an auto-repair-junk-yard gas station.
With a screwdriver in one hand and a large wrench in the other, an old mechanic kept plucking parts from various makes and models.
With no auto parts store in sight this mechanic had no choice but to practice reusability to it truest sense and borrow parts and pieces from all sort of various cars to fix mine.
For the past fourteen years I have been a programmer in Silicon Valley and have taken part
in projects ranging from large to small. Years ago I would have not dared to bring this up and talk about it because I never thought my experience was the norm. But after many years of work I can talk about my experience on software reusability: it is, for a large part, just a myth.
(That feels so much better after years of holding that inside.)
I am not talking about reusing Java string functions such as String, StringBuilder,
StringBuffer—or any general-purpose utility that everyone uses.
I am talking about business objects, and key functionality components of an application.
"...oh we'll write it from scratch and we'll get to know it inside-out..." , a tech lead once told me when the decision came up on whether to rewrite or reuse a component. And there is a lot of truth in what he said.
With deadlines looming over our shoulders we do our level best to write code as fast as possible. We do our level best to make it modular and reusable. But somehow when time is up for a new project we always opt for a rewrite from scratch. It just seems so much easier to reinvent the business application than to reuse parts from an existing application. Why is that? I just don't know—this is simply career-long experience so far.
Having meditated over this for several years here are my top reasons why reusability is more of a myth:
1. Business modules are not always well-documented and currently-updated. Most of the time the engineers rely on the JavaDoc as the sole form of documentation. So when the time comes for a new project, it is always easier to "rewrite" than to "reuse" as there is, for most part, very little "currently-updated" documentation around.
2. Lots of times the original engineers that worked on a project move away to other—hopefully better projects—or they just get promoted to CTOs, or even win the lottery by getting hired by Google...
Then, in turn, the new less experienced engineers that take over will always opt to re-build from scratch; and rightly so—since it is so much easier that way.
Here are my two top questions on reusability:
1.Is reusability something that one can train for?
Is this something that can be taught in school. And I am not talking about writing a project and then reusing the same project for the next assignment. What I am talking about is reusing something that someone else has written for the same domain but a different application. You see that is so different than re-using the previous project to build the next programming assignment—it is more real-life. Building over a previous project that one has written is not so much training for reusability since one knows all the parts inside out.
2. Is reusability for key business objects and application modules a concept that has to be dictated as a requirement?
As for the old mechanic, I am planning to drive down and meet him one day, years after he fixed my car,and ask him if anyone taught him reusability and if he had any thoughts or tips on the concept of reusability in the software business!
Please feel free to add to the above two lists (reusability as a myth, and reusability, questions.) This way, maybe if the list is long enough and potent enough someone high up in the world of software design may just pay attention and come up with a new directive on reusability. Who knows?
My experience is similar to yours...but I wouldn't be so dismissive about how far we have come in reuse of non-business objects.
We have done better and better at separating the code that addresses problems in the business domain from the code that addresses problems in the technical domain.
10 years ago we all wrote our own http servers and template rendering code and authentication schemes and remote procedure infrastructure and xml parsers... we don't do that any more.
The real answer to your question is probably that writing reusable business objects is hard because the requirements are poorly understood and continually changing. There are only so many ways that we might generate an html page - and we all use one of a handful of libraries to generate html - but every bank gains business advantage from continuously refining, say, how they apply finance charges.
Rather than think of this as a failure to solve a problem, I think of it as a realization that it was the wrong problem to try to solve. XP teaches us to solve today's problems rather than tomorrow's. I think that's a good lesson.
Kevin www.junitfactory.com You send us code. We send back tests. For free.
This should be paired with "The Big Rewrite" threads from a couple weeks ago. Seems kind of like a damned if you do, damned if you don't kind of situation. Maybe all programmers are masochists.
But seriously, whenever you do something new you always think you have "better" requirements than before, and what was done before was never done anywhere near was well as intended.
The previous post is right. We have come a long was in terms of reuse. We aren't writing custom OSes anymore, databases, web servers, web frameworks (well...), templating engines, etc. That's a lot of reuse. I think reusable components will keep on coming closer to the domain but never quite reach it.
Rails has a strong tendency to discourage certain types of code reuse and over-generalization. They try to make it easy to build things the way you want it from scratch.
I think there are a couple reasons for the lack of reusability you mention.
1. Most business logic is not reusable. It's just a fact. A lot of the business logic people are writing into code is unique logic. You don't need two rules that say the same thing. If you actually need two rules, it's because they are different. Note that I am talking about actual need and not any sort of mistaken perceived need.
2. In order to write reusable code, you have to have a strategy for reuse. A lot of people will tell you OO is one such strategy and they are wrong. OO can be very useful in creating reusable components but it's not the only one and by itself doesn't solve anything. Just because you use objects in code doesn't make them reusable.
The biggest mistake that I made and that I see other's making in trying to make code reusable is thinking that increasing scope makes code more reusable. There's a balance but usually increasing scope decreases reusability. Making the code more general increases it's resuability and the difference is the key, in my experience. In your junk yard example, the mechanic wasn't trying to replace your engine block with another one. He was using small pieces that by themselves do very little, right?
For example. Lets say I have a class: WashDishes and a class SoakAndWashAndDryDishes. The second one is less resuable because if all I want to do is wash the dishes, I can't use it. So perhaps you recognize this and put in switches to turn on and off the different features. I've seen and done this and the technical term for the result is 'a pile of shit'. Not only does no one ever want to reuse it, it's a pretty poor implementation of it's original function.
I think a lot of this comes from too much focus on class inheritance and not enough on composition. I've actually been trying to figure out if it would be possible to write an 'OO' language without any implementation inheritance but with syntactical support for composition.
Every project starts from scratch? Really? You start by writing servlet and go from there?
Or do you reuse servlet?
The only code you can reuse is code that does something that you want to do again in some other context. Precious little application code fits that. Some does and if it does, make a library, write some tests for it, give it a blog and a url.
> I think there are a couple reasons for the lack of > reusability you mention. > > 1. Most business logic is not reusable. It's just a fact. > A lot of the business logic people are writing into code > e is unique logic. You don't need two rules that say the > same thing. If you actually need two rules, it's because > they are different. Note that I am talking about actual > need and not any sort of mistaken perceived need. > > 2. In order to write reusable code, you have to have a > strategy for reuse. A lot of people will tell you OO is > one such strategy and they are wrong. OO can be very > useful in creating reusable components but it's not the > only one and by itself doesn't solve anything. Just > because you use objects in code doesn't make them > reusable. > > The biggest mistake that I made and that I see other's > making in trying to make code reusable is thinking that > increasing scope makes code more reusable. There's a > balance but usually increasing scope decreases > reusability. Making the code more general > increases it's resuability and the difference is the key, > in my experience. In your junk yard example, the mechanic > wasn't trying to replace your engine block with another > one. He was using small pieces that by themselves do very > little, right? > > For example. Lets say I have a class: WashDishes and a > class SoakAndWashAndDryDishes. The second one is less > resuable because if all I want to do is wash the dishes, I > can't use it. So perhaps you recognize this and put in > switches to turn on and off the different features. I've > seen and done this and the technical term for the result > is 'a pile of shit'. Not only does no one ever want to > reuse it, it's a pretty poor implementation of it's > original function. > > I think a lot of this comes from too much focus on class > inheritance and not enough on composition. I've actually > been trying to figure out if it would be possible to write > an 'OO' language without any implementation inheritance > but with syntactical support for composition.
I generally agree with this - the more a component does the less reusable it will be because it assumes more specific context in which it can function. I think that's why reusability in hardware is more common, since basic hardware components are generally very simple. There is, however, lots of reuse in software too - for example, I believe anyone who programmed in C used functions like strcmp, strcpy, atoi, itoa, getc, gets, etc. These functions are very simple, general and thus highly reusable - all they need is one or two arguments. As you implied above in your example, the problem might not be that a component does a lot, but that it's not properly composed of simpler components that are themselves reusable. I just think that both inheritance and composition are useful approaches to reusability, but that might depend (among other things) on the language you're using. For example, in C++ it is more often recommended for reuse to use composition instead of private inheritance, while in Eiffel I've seen examples of correct reuse approach using (multiple) inheritance. Of course, it also depends on the specific components you're trying to build. Also, as you implied above, reusability must be one of the goals when building components - there is no paradigm that can just produce reusable components by itself. I think building software for reuse is hard because you have to think about the specific problem you're solving, but at the same time you also have to think outside of the problem in order to create reusable components, so you need to kind of switch back and forth between the specific solution and an abstract and general one.
Where I work we managed to acheive a good reusability of back-end business components. We've done that following a few principles and technics: - design documentation and peer reviews - layering and separation of concerns in mind - composition rather than inheritance - inversion of control
However, what makes a new application? The "Big Rewrite", when triggered by technology change (the only good reasons to me) oviously do not make use of existing components (not talking about technical frameworks). When you create a new piece of software, is it a "new application" or is it a new part of an existing system? If you do not integrate an existing system there are chances that there is nothing reusable (beside tech stuff) unless you integrate with third party software/libraries. If you integrate an existing system and it's not reusable enough, then be agile, make it move.
> Where I work we managed to acheive a good reusability of > back-end business components. We've done that following a > few principles and technics: > - design documentation and peer reviews > - layering and separation of concerns in mind > - composition rather than inheritance > - inversion of control
I agree with all of these but I would add minimizing coupling between components and almost (if not completely) eliminating all coupling to the internal implementation of a component. One of the biggest tools for reuse of code is commonly called 'refactoring' in the Java universe. Because we are developers and not clairvoyants, we are unlikely to anticipate future uses of the components we write. I tend to avoid building in functionality I don't need right now and always write code with the thought in mind that myself or someone else will want to change it later. A component that can be honed and tweaked is going to have better chance of being reusable than one that cannot change.
> I just think that both inheritance > and composition are useful approaches to reusability, but > that might depend (among other things) on the language > you're using. For example, in C++ it is more often > recommended for reuse to use composition instead of > private inheritance, while in Eiffel I've seen examples of > correct reuse approach using (multiple) inheritance. Of > course, it also depends on the specific components you're > trying to build.
I didn't want to imply that inheritance should be eliminated (although I've heard that said) but I was thinking more as a thought experiment and perhaps an actual experiment (if I finish all the other side projects I'm working on) to see if in fact composition can replace inheritance entirely. There are definitely things that you can't do with inheritance (at least in statically checked languages) that you can do with composition but I've yet to see something that you can do with inheritance that you can't do with composition. And I don't mean in a Turing complete sense here. I mean in terms of realistic development techniques.
What does bother me a little, though is that every language I know of makes inheritance easy while leaving you pretty much on your own with composition. In static languages like Java and C++ where composition is preferable, this seems kind of bass-ackward.
> Because we are developers and not clairvoyants, we are > e unlikely to anticipate future uses of the components we > write. I tend to avoid building in functionality I don't > need right now and always write code with the thought in > mind that myself or someone else will want to change it > later.
I completely agree with James' statement here. I found that the components I tend to reuse the most are, paradoxically, the ones I never planned for reuse. The reason maybe that those components are so simple that they easily lend themselves to reuse in different contexts, whereas components I intended for re-use tend to be over-engineered.
In general, I found that components that carry little context with them are easier to reuse than those that require knowledge of a lot of context. Canonical examples are the Unix utilities - you don't have to know a whole lot about them to start using them. And once you start using them and find how useful they are, you start using and re-using even more, combining them in scripts, etc. While they have many features, there is a low barrier to entry to use (and re-use).
At the other end of the spectrum are frameworks that require knowledge of a lot of context from the developer. Anyone remembers the San Francisco Framework (IBM)? That came with something like 500 pages of docs - you had to pretty much read that in order to get value from those supposedly reusable components.
> In general, I found that components that carry little > context with them are easier to reuse than those that > require knowledge of a lot of context. Canonical examples > are the Unix utilities - you don't have to know a whole > lot about them to start using them. And once you start > using them and find how useful they are, you start using > and re-using even more, combining them in scripts, etc. > While they have many features, there is a low barrier to > entry to use (and re-use).
The unix utils are a perfect example. Take uniq and sort. I pretty much always call sort and pipe that to uniq. Given that I always sort before calling uniq, if I had been the author of uniq, I might have been tempted to write uniq to have a built in sort. But not every use or user would require a sort. Sometimes the data might already be sorted or I'm doing something sophisticated with unsorted data. So by using composition here instead of reproducing the sort functionality or bundling it into uniq, the utility can focus on it's intended purpose. This makes is simpler to write and maintain and easier to understand.
I've seen Java projects where no useful sub-portion of it could be re-used in another project without major rewriting. This comes from not properly understanding OO Design Principles. The non-reusable classes were coupled not only to many other concrete classes in its package, but also coupled to packages below it and above it in the package heirarchy.
If each of these classes had been developed using Test Driven Development (or BDD - "TDD done right"), its first "client" would have been a test-case. It would be usable without being tied into a whole lot of other classes and packages. Many or most of the collaborators that the class needs would have defined in terms of interfaces or abstract base classes instead of concrete objects.
An important skill in doing TDD - or any OO programming "done right" - is recognizing Code Smells. Apparently it's easier for many people to recognize a code smell (Feature Envy, for example) than to recognize violations of Design Principles (Maximize Cohesion and Minimize Coupling, for example).
For example, I had to develop an application that computes the charges of the airport to our airline for facilities, landing and other charges. I am talking about 35 different airports, each airport has a very special way to charge you, and different charges, but there were some similarities. So, we start analyzing each charge for each airport and find the similarities and differences. We have not created one business object for each calculus, we created some, and others we adapted them in order to reuse the code. Yes, maybe it was a requirement, but it was simple logic to reuse the code. New airports appeared in the way, more charges were added to some airports, and it did not mean that we had to create new objects, just reuse them.
> For example, I had to develop an application that computes > the charges of the airport to our airline for facilities, > landing and other charges. I am talking about 35 different > airports, each airport has a very special way to charge > you, and different charges, but there were some > similarities. So, we start analyzing each charge for each > airport and find the similarities and differences. We have > not created one business object for each calculus, we > created some, and others we adapted them in order to reuse > the code. Yes, maybe it was a requirement, but it was > simple logic to reuse the code. New airports appeared in > the way, more charges were added to some airports, and it > did not mean that we had to create new objects, just reuse > them.
That's an interesting example, because it highlights different meanings of reuse. I think several people on this thread may have meant reuse across different projects, whereas your example illustrates reuse within one project.
Flat View: This topic has 46 replies
on 4 pages
[
1234
|
»
]
Previous Topic
