Skip to main content


Posted by editor on July 25, 2007 at 7:28 AM PDT

Value of your supposedly reusable code: $0?!

We know that code reuse is important. Everyone's sick of writing the same things multiple times, wasting effort when surely there's some similar code that you wrote six months ago that could surely be refactored to serve both its old purpose and the new thing you're writing.

Or... not.

What if code reuse isn't all it's assumed to be? Maybe the reason we don't do it isn't that we're bad programmers or badly managed, but because code reuse isn't actually a good idea?

InfoQ quotes from a pair of essays on this topic in Code reuse highly overrated?. The first, Dennis Forbes' Internal Code Reuse Considered Dangerous from 2005, rails not against the abstract idea of code reuse, but rather against how it is typically practiced in the wild. A company will build up its own internal set of libraries, frameworks, components, etc., seemingly for reuse but in fact deeply tied into the company's own purposes, processes, and pathologies. When a new developer is told to just reuse this material, they often find it is nowhere close to reusable -- such internal products are typically shoddily documented, inadequately tested, and not really meant for reuse beyond the small number of projects already using it. Forbes says the key is an objective analysis:

The question every organization needs to ask itself, then, is what value they could sell their "reusable code" for - what, realistically, would competitors and new entrants in the field offer for it? The answer, in almost every case, is $0, and they wouldn't want it even at that price. There is extraordinarily little code theft in this industry (even though we're in the era of burnable DVDs and USB keys) because most code - above and beyond the industry-wide frameworks and libraries - has no value at all outside of a specific project with a specific group of developers. Trying to use it for other projects is often worse than starting with nothing at all.

In Is your code worthless?, Carl Lewis follows up with an anecdote about the reuse side of this equation. Tasked with integrating his company's code with a customer's, he found the customer jealously protective of its precious IP.

Since this customer was a big fish, I was sent to complete the integration at the customer’s premises. I arrived on a Monday morning and was shown to my cube where the hardware I needed was already assembled. I sat down and fired up Vim to start looking at their code and was INSTANTANEOUSLY BLINDED by the reeking bile that was pouring across my monitor. Even if I or my company were interested in marketing a product that did the same thing as the customers product, the last thing we would ever do is steal this code. Incorporating their code into our product would have meant incorporating all their bugs into our product, and from the look of it there were probably a couple for every hundred lines.

Forbes' original commentary basically says that unless your code is generally designed for industry-wide consumption, it's not going to get reused (or stolen, for that matter). He's also pretty pessimistic about how many fields don't have such libraries already available.

This is an interesting sacred cow to see punctured. In some ways, you can see this argument echoing the agile methodologies' claims that "you aren't going to need it", except that instead of arguing in premature feature builds, this time the feature to not worry about is reusability. There may also be a counter-argument to be made that while a company is unlikely to develop generally-useful libraries, an open-source process may be better suited to developing code that is reusable, as more eyes from more POV's can potentially weed out the assumptions that limit the code's uses.

But what do you think? Do you reuse internal code productively, or would you have been better off reinventing just the right wheel for your project?

Also in the Java Today section,
the JCP office notes that the organization has a new Chairperson. "Starting this month Onno Kluyt is stepping down as Chair of the JCP moving on to new
roles and responsibilities within Sun. Onno led the community as Chair since July 2004 and managed the JCP Program in several capacities prior to that. Patrick Curran is the new Chair of the JCP. He has a long-standing record in the software industry and in conformance testing. Find more about Patrick on his JCP profile page. The formal handover will take place at the next JCP EC meeting in August in Munich, Germany."

The Help Wanted section "is both for developers looking for an interesting project to work on and for those involved in a project who are looking for someone to fill a particular need." Current postings seek developers skilled in file processing, converting to EE, testing, and documentation... and you can visit the page to add your own. Note that this service is limited to the open-source projects on the site; commercial job postings should use our JobsWiki.

In today's Forums,
Kleopatra tries to avoid a SwingX design smell, in Re: AbstractTreeModel, do we need one?
"My answer is a no. The Abstract* layer in the other models is an abomination, forcing developers into inheritance instead of delegation. This leads to code duplication (smelllly) if they can't extend, f.i. if a model needs to serve more than one xxModel interface. SwingX has the TreeModelSupport which does the notification. There's not much more a Abstract* layer can do in the general case. That said, in my early days in the project there had been an interesting discussion between Patrick and Ramesh about how to support easier treeModel handling. Didn't follow it at that time, and don't have the link, but searching the forum might turn it up. And there should be some code in the incubator (under the old tree src/java/ tree)"

cpesch is working through native library deployment hassles, in
How do I start a JDIC based application from a _single_ jar?
"I am currently providing my application RouteConverter in a single jar, which makes deployment and installation for the users pretty easy. To display Google Maps, I'm experimenting with embedding a web browser which looks very promising, but... I only found a very clumsy way for jdic.dll and IeEmbed.exe: Extracting them to the directory where the RouteConverter.jar is located. Besides patching the JdicManager and WebBrowser classes - is there a more elegant way?"

Ken Warner explains scaling algorithms and their applications, in Re: [JAVA2D] Why isn't BILINEAR scaling smarter?
"Bilinear interpolation uses a very small 4 pixel neighborhood to interpolate. My experience is that it works pretty good at upscaling -- maybe not so good at downscaling. Other interpolation methods work better at down scaling because they use a larger neighborhood. Bicubic; Lanczos etc. use a 16 pixel neighborhood and they do better at downscaling because they take a weighted average over a larger neighborhood."

In today's Weblogs, Fabrizio Giudici works through the gotchas of
Using the NetBeans 6 M10 profiler with Tomcat and Mac OS X
One of the (many) neat features of NetBeans, coming from older versions but improved in 6M10, is the integrated profiler. Since NetBeans comes also with an out-of-the-box integration with Tomcat (and other application servers), theoretically profiling your web applications should be just a matter of pushing two buttons.

Neto Marin checks back in with
Getting started with JME - Part III / III:
"Today, be connected is more than a simple feature of a mobile application, it's a requirement! Let's finish this trilogy talking about JME connectivity."

Finally, in
The Gods Must Be Crazy - Java Edition, Felipe Gaucho offers
"sample code to expose the secret Calendars in your JDK."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Value of your supposedly reusable code: $0?!