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.)


  • 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?

  • 1
    The only real answer to this is 'it depends'. It depends on exactly what you're product is, if newer versions of frameworks or libraries you're using bring significant performance, maintenance or security advantages, how hard (well, time consuming) and well equipped you are to make the changes necessary to make your software work with the newer frameworks and libraries, and so on.
    – Anonymous
    Aug 6, 2012 at 15:48
  • Aren't broke - don't fix. Aug 6, 2012 at 15:58
  • 2
    @NikolayFominyh Although change for the sake of change is bad, that kind of attitude often leads to poorly maintained and poorly understood software that breaks in the most inconvenient way possible. As Martijn points out, eventually vendor drops support, or you need a bug/security fix. The longer you've put off upgrades, the harder it will be.
    – Roman
    Aug 6, 2012 at 16:49
  • "Never touch a running system" sounds simple, but in my opinion, depending on the system lifecycle, it's not always a reason. If you're already in maintenance mode, I would not spend too much time upgrading. But the system is still evolving and new features are added, so staying up to date will be definitly necessary.
    – Volker
    Aug 10, 2012 at 14:44

3 Answers 3


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.

  • Thanks for your advice. Measuring the costs of upgrading vs. staying is a good descision support and looking at what we have so far, upgrading seems to be really necessary. I'll accept your answer, because you provided various other thoughts about the general dev/upgrade process.
    – Volker
    Aug 10, 2012 at 14:42
  • At one time I was asked to maintain an old Visual Basic application. The first thing that happened when I inserted the Visual Basic cd into the computer was that Windows popped up a warning screen that this was UNSUPPORTED SOFTWARE (or something similar to that). I took that as a hint that it was time to switch. Nov 7, 2015 at 0:36

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.

  • Thanks for your advice. Setting up a solid and covering testing environment seems to be the way to go - BDD sounds quite interesting and I will definetly have a look at it.
    – Volker
    Aug 10, 2012 at 14:37

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.