Not everyone is working on projects for the Defense Department where milliseconds could mean the loss of thousands of lives.

And not everyone is working on the backend for the stock exchange.

And most people are not writing their own application servers from scratch.

What are most people working on? Well that is a little hard to quantify, but it is a pretty safe bet that it is not a sexy application that they are bragging to their friends about. If you believe the 80/20 rule (and I do), most people are actually working on maintenance activities more than inventing something new from the ground up. Those who are inventing things from the ground up are more likely to be building a .com site for their company to show off their wares – it might even have an element of ecommerce to it, but then again, probably not.

So we are bombarded with hype about new versions of tools (like IDEs), or new libraries (like a new JDK), or a new package (like a new object-relational mapper). But do we even need them? Can’t we basically create what we need to complete these mundane everyday tasks with the tools we already have? Aren’t most of these new releases just a way to sell new licenses? Even when it comes to open-source , upgrading to a new release has an inherent cost that needs to be weighed.

Here is a real world example. I am currently invovled in a project that involves upgrading the base from JDK 1.4 to JDK 5 as part of the scope. My engineer brain says that this is not only necessary, but just a plain good idea. There are some new language features in JDK 5 that we can take advantage of, so there is a benefit. But what are the costs? There is definitely a cost involved in doing an audit of the existing code and seeing if there is any code that is incompatible for the new JDK and putting together a plan and effort estimate to address those issues. There is also a optional cost of retrofitting the existing code to take advantage of the new language features (like enums for example). There is a learning curve cost. Perhaps there is a confusion cost for some junior (I am thinking of the autoboxing feature). There is a cascading cost that we now also have to consider upgrading our application server environment to support the JDK 5 code.

So is all of this cost worth it? Will the benefits outweigh the risk and give the company some kind of ROI? I think in most cases, the answer is actually a defiinite yes.

Take the Java 5 upgrade example. Apart from the obvious technical benefits, there are a whole host of trickle down positive benefits. For starters, I think many companies underestimate the importance of keeping the geeks happy. Engineers like to use new tools and stay on the cutting edge. They like to be able to read in the latest journals and be able to apply the lessons learned straight away. Happy engineers are good employees. They are more productive. They are more collaborative. They tend to not be looking quite so hard for that next dream job. They tend to be more forgiving of working conditions that might not be ideal. Engineers are creatures who like to learn and keep learning. Working on the same code and project and tools for year after year will be the death of an engineer and you will end up with just mediocre hackers left on your team as the engineers will be long gone.

So before you decide on your next upgrade, think about all of the costs involved, there are many hidden ones you may overlook at first glance. But then make sure you also think about all of the benefits (both short and long term). Not every upgrade will make sense, but I bet that a majority of them will.