Sponsored Link •
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?
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
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?
|Arash Barirani is a developer with a taste for fast software and fast cars. He enjoys reading Artima.com, and likes to comment on questions that have no real answers. His favorite subject area is user interface design and performance bottleneck resolution.|