When, how and why should one upgrade (Java) frameworks?

Question

Short summary as introduction:

We are a small Java web development team, creating applications using various frameworks and libraries like JSF, Hibernate, Seam, all together deployed in JBoss AS.

Initially, the app was put together and some features added to form a showcase to show to potential customers. Some polishing took place, the app got released, it was accepted and working and as time went by, additional features were added, bugs got fixed, new bugs occurred, as it always is.

Due to high bus factors and startup racing, development got a bit out of hand - more and more features were added, not having fully understood the core architecture of the system. It's still working, but there are always pitfalls because the system evolved from where it originated to something else and in the beginning, various shortcuts were taken to speed up development - now all this comes back and development slows down, because workarounds are used and it's fairly hard to introduce new developers into the project.

Now, I'm in the progress of cleaning up and organizing things - installing a bug tracking system, build up a testing/quality culture, thinking of how to do automated testing, code reviews (all that fancy professional stuff we were lacking in the beginning) and doing general refactoring like organizing class hierarchies and functions to make it easier to use stuff. That makes everything a bit better, but there is still a lot to do. As I'm not the person who initially build the system (former lead programmer left) and not that experienced (developing for 2.5 years now, but that's my only 'open world' experience so far), I'm not always sure what to do.

Here's my problem:

Refactoring is always something good and I'm constantly doing it to make things easier, but what puzzles me is when, how and why I should upgrade the basic architecture (that means, libraries the system relies on, application server, database etc.)

Examples:

• We are currently using JBoss 4.2.2 - I read somewhere of JBoss 7.1 already out, should I go for that? How can one evaluate this?

• We use Seam 2.2 what seems to be a big blocker (does not work on higher JBoss versions, doesn't support JSF2). In addition, I see sources telling me to use JEE features instead of Seam.

Basically, I'm interested in any generic approach for this problems, not only the ones I mentioned in the examples above - as I may stumble over this problems for another library on another system in another time (or someone else may face similar problems).

So, what's the point? Shall I be up to date and use only cutting edge libraries or should i stay with what i have? How do I recognize, the technology I am using is literally a dead horse and jump off? How often should such technology upgrades appear?

And, another question beside the general 'how to do upgrades'-stuff. How do I recognize my piece of software could be called one 'crafted by professionals'?. Is there a Joel test for well-done software besides common programmers sense?

Answer 1

The short answer is that you switch when the effort to not switch exceeds the effort of switching, or when you can foresee that it will soon become so. That's a very subjective assessment which requires experience, but it's relatively easy to see the extreme cases.

For example, say you estimate one month to switch, but not switching means you can't use a module that's only available in the upgraded version, so you'll have to take two months to implement one from scratch. The choice is easy.

For another example, if you are spending all your time fixing security vulnerabilities in software that is no longer supported by the vendor, it's a good time to switch.

If you never have meetings where someone says, "This would be a lot better/easier with the new version," then you probably don't need to switch.

The in-between cases are harder to recognize, but it usually feels like building pressure, where sticking with the old version feels more and more limiting.

As far as your well-done software test, your bug tracker provides a good rule of thumb on that. When you have zero critical defects and your list of non-critical defects is at a reasonable level and steadily shrinking, you can call it 'done.' You can get a sense of your software architecture quality by the turnaround time for adding new features or fixing bugs. There's no cut off point that says, "this is professional," but the lower the better.

Answer 2

There are a number of reasons why you might want to upgrade your underlying infrastructure, and you should evaluate each of them as empirically as you can. For example, you might upgrade because:

1. The vendor is no longer supporting the version you're using
2. There's an critical bug or security fix
3. There's a new feature you want to take advantage of
4. It will increase your velocity
5. There's a direct capex cost reduction in upgrading (cheaper support license or similar)

These reasons needs to be weighed up agains the cost of upgrading, most of which is spent in testing. This is where TDD / BDD really comes to the fore, especially when combined with a good CI setup.

It means you can "Refactor rapidly without fear"

If you don't have a decent comprehensive test suite in place, it means you're manually testing, which is time consuming and very error prone, raising cost of upgrade.

Answer 3

The technologies that you've listed are widely used, it's easy to find documentation for them and people who are proficient with them, so I think there's no real reason to change them. On the other hand I'd recommend to upgrade your frameworks to the latest released versions. I think you will need to do it anyway, sooner or later (if not for new features and compatibility with newer libraries, then to the bugs fixed in new releases), and the earlier you do it, the less tedious this task will be.