The first rule of poker is finding reasons to fold your hand.

That’s what my colleague Marco Tolesano told me yesterday. And what a great metaphor for software development that is. We spend too much time thinking about why we should be doing something. Why not concentrate on why we shouldn’t be doing it?

Here’s a typical scenario: Blog savvy developer finds out about the latest cool magic offered by cool framework X. Promptly downloads the jars, fires up his fave IDE, creates a new project, chucks a bunch of jars in the lib directory and writes a few XML files. Kick-starts the app – NoClassDefFoundError.

Hmmm… I’ve seen this before.

Pastes the stacktrace in Google, the people on the forums say that dependencies A and B are unsatisfied. Easy. Downloads a few more jars and adds them to the classpath. Repeats this process a few times. Still doesn’t work, because the developer doesn’t yet fully understand how the framework works and how to set it up. In true developer fashion, the verdict is quite unfavorable towards the framework. What we don’t understand is lame.

Because our developer is persistent, though, and because he’s been reading more and more posts on JavaBlogs about the framework being the one to end all of the world’s problems, he gives it another shot. A few more jars later and a little bit more of reading the documentation and fiddling around with the configuration…

Hey, it works! Boy this is cool. Look, mom, I don’t have to write any code.

As developers, the more we understand something, the highest it scores on our list of what is good and what isn’t. You’ve seen it happen. Knowing how something works somehow makes it part of us. We’re prepared to go to war to defend something we understand if somebody has something negative to say about it.

Back to our story, it is needless to say that by now the lib directory weighs 44.9 Mb. 99.5% of the dependencies introduced are unused, but who cares when code looks so clean, when it’s the framework that takes care of everything behind the scenes.

A few weeks later, the 44.9 Mb have been added to the existing 151 Mb of the .ear bundle of the project the developer is working on for his employer, along with all the issues and bugs that come with 44.9 Mb of framework code. Everyone thinks this addition to their armory saves them time and makes the code cleaner, even though they have to write more XML than the actual code it would have taken them to achieve the same goal. Even though they have to spend 2 days running around when something goes wrong, trying to figure out what it is.

Here’s what I think: I think that we have taken the whole ‘code reuse’ concept a bit too far. Or, perhaps, we got it slightly wrong. We put too much focus on knowing what’s out there, so we can incorporate it in our work to make software better, and most importantly deliver it faster. The ‘velocity through knowledge of the tools for the job’ issue can be very tricky if it isn’t approached with caution.

For those of us out there who have had to deal with legacy code, do you remember how it feels when you figure out that the problem you’re trying to solve is due to a five year old library that’s not supported any more? Five years from now, there are still going to be developers who will have to code on Struts releases that came out in 2004. Surely that can’t be right.

Replacing code with declarative framework configurations doesn’t make the codebase cleaner. It makes it difficult to maintain. And it doesn’t save time, because when something goes wrong it takes hours of effort and frustration to fix. And most of the time, if we spend half an hour to figure out what it is the framework does to attack the problem at the hand, we’ll realize that we can do the same thing in 5 lines of code, most importantly avoiding all the dependency garbage the framework will force in our classpath, because Java frameworks are trying to be too generic, but usually end up just being overweight.

I suppose the need for third party libraries is largely due to the fact that Java’s core libraries justify the existence of something like the Commons packages, but let’s not get into Java’s shortcomings here… On the surface, there’s nothing wrong with that. Code reuse, dude. Until those libraries are out of date and not very well supported.

Everyone loves saying “don’t reinvent the wheel”. But most of the time it’s not about that. It’s about making a better, lighter, rounder wheel that’s exactly fit for the kind of terrain your car will roam and will be easier to change when you get a flat tire.

For my part, I’ll try harder to find reasons as to why I should fold the latest hand I’ve picked.

Seven or Eleven, snake eyes watching you, Double up or quit, double stake or split, The Ace Of Spades , Lemmy Kilmister once said.

Digg gambling

This entry was posted on Friday, July 7th, 2006 at 12:16 pm and is filed under Software. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.