I think it’s fair to say that I have worked in a few places during my time in IT. The same issues, problems, discussions seem to pop up all the time. One of my biggest annoyances is that the moment a dependency is added into a development project, it’s cast in concrete. Getting rid of that bug that’s been fixed in a newer version of a Jar always has to be balanced against the risk that something is going to break. Your program may still compile, but what if some strange behaviour has been introduced under the covers? And when you’re on a time-limited project (aren’t they all), no justification seems to be enough to move forward.
That problem seems to be compounded with JVMs. In theory, the vast majority of Java programs will run on a newer JVM. An upgrade may give you newer features (annotations anyone?), a performance increase and nicer APIs. But that’s not the only reason to upgrade! You may not necessarily need or use any of those thing, but newer dependent libraries in your project might. How many times have you sighed as that great library you wanted to use that would save you days needed a better spec’ed JVM? Is it worth the effort or is this just a fact of life?
What are the human factors in getting that upgrade approved? Should upgrades be factored into maintenance on a project as a necessary thing? If approved, how do you manage the risks and prove that your code will run as before – particularly if as with most places, no automated unit tests are in place.
We are going to be covering some of these issues at the Dublin JUG tomorrow night. Anyone interested in coming down and having their 2 cents on the subject should drop by at the Forum Bar on Dame St at 7:30.