Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In large scale applications (e.g. Banking Domain), what is the criteria of upgrading an existing project to a newer version of the technology on which it is built?

For instance, a .NET application built on .NET Framework 3.5 and using Oracle 9i back-end. There are not any specific urgent requirements, but should I think of upgrading to .NET 4.5 and Oracle 11g in the near future?

Is it advantageous to keep pace with the technology version?

share|improve this question
6  
When you have the time and money to thoroughly test the new versions. –  user1249 Mar 13 '12 at 11:40
add comment

6 Answers

up vote 3 down vote accepted

Additionally to two previous answers, consider the following elements:

  1. The users.

    There are lots of applications which force the companies to stay using very old software: Windows XP, Internet Explorer 6, etc.

    At some point, the company employees may be unhappy to use such old software, when at home, they have the newest MacOS, or the latest Chrome, or anything which allows them to compare daily the software as it is today and the software as it was twelve years ago.

    If it's about upgrading from .NET Framework 4 to .NET Framework 4.5, the users don't really care.

  2. The developers.

    Too many developers are geeks. Too many geeks want to use the latest technologies, and the features they provide.

    I will be unhappy using .NET Framework 3.0, because there is no LINQ, no Code contracts, no Reactive Extensions, no hundreds of things I like using.

    At some point, it becomes critical to upgrade. If, in 2012, you still use .NET Framework 1.0, you just will be unable to hire the greatest developers.

Those two points force you to upgrade from something too old to something recent. This doesn't mean that you will always have to install the most recent software. Consider:

  1. The users.

    Great software is great. But you can't be productive in a company where the software changes twice per year and each time there is a learning curve for it.

    The upgrade process itself is very disturbing too. You can't upgrade from Windows XP to Windows Vista seamlessly in a way that the user will not even notice it. You will have to make backups, to reinstall some software. This takes time during which the person will be unable to do his work.

  2. The developers.

    Being geeks, the developers still know that they must concentrate on the technologies which are used today by their customers. If 85% of customers still use .NET Framework 3.5, 9% - .NET Framework 4, 5% - .NET Framework 2.0 and 1% - .NET Framework 4.5, it's much more interesting to spend time learning better the .NET Framework 3.5 then to explore the features of async, compiler as a service, etc.

share|improve this answer
    
I think 85% are still on .NET 2.0. Probably not that bad, but I'm sure there's a good percentage that haven't migrated to the VS 2008 tools yet. And remember .NET 3.0 was not standard with VS 2005. –  Mike Brown Mar 13 '12 at 12:59
add comment

In any large scale application you need to take a look at the risk, costs and benefits of such a change.

The risks in changing platforms can't always be foreseen - software becoming buggy due to changes in the underlying OS/Framework etc. Of course, there are risks in remaining on a defunct platform (say staying with DOS 6.22 or with classic ASP/Cold Fusion) - both in regards to support available and finding developers.

Costs can be incurred in testing and proving that the application is still working correctly and in upgrading to the new platform (and possibly in training users).

All these need to be weighed against the benefits this change will bring to the business.

share|improve this answer
add comment

You need to weigh up the business case versus the cost. If there are no clear business benefits, no security issues, and no clearly defined reasons to upgrade other than version number then stability is something to think of.

That being said, it's also worth doing an analysis of what it would take to upgrade the application now while it's not too far behind.

share|improve this answer
add comment

There are no set criteria for needing an upgrade except if a piece of software goes out of support. If you are running IE6 now there is no support for instance.

You have two conflicting parties here:

  • The client/business wants stability and cost saving
  • Developers want newer technologies that are easier to work with

You need to have a safe upgrade path. Because you can't satisfy both parties, I would recommend the following:

Create an integration environment that is focused on upgrading software to it's newest versions. This branch of the software converts and compiles the older software. Developers still work on the old versions, but their code is also compiled against newer software. The integration branch shows upgrade path problems like use of deprecated functions etc. When everything is stable you can present a business case to upgrade, and at that point it needs to be based on the following:

New versions offer the following advantages:

  • performance improvements
  • easier configuration
  • security improvements
  • more attractive to developers
  • keeps you from falling behind
  • easier development
  • more productive
  • more competitive

So even if you skip one upgrade somewhere in your business you should be integrating with newer versions of software, even if you don't use the new features. This will make life easier when you eventually upgrade.

There is another advantage to constant upgrades. Your code-base will improve because bad code bases often stay in old technology because they are difficult to upgrade.

This phased approach can help you avoid bad and massive rewrites in the future.

share|improve this answer
add comment

The short answer is that you upgrade when the benefits of upgrading outweighs the cost of upgrading.

Calculating the cost/benefit is another story. Benefits do not have to be limited to only new features, it can also be eliminating cost or risk associated with NOT upgrading.

When you make a decision, however, you have to look at the whole board. Just because something is "end-of-life" doesn't automatically mean you will upgrade. The cost of doing so may still be high enough to warrant the additional risk of running with an unsupported version. ATM-machines where I live ran on OS/2 Warp for years after IBM dropped it completely. The reasoning was "they are running fine now, have been running fine for years and we're not planning on changing anything" so they decided to accept the risk since replacing all those old ATM machines would have been prohibitively expensive.

Those ATMs have all been replaced now, but that didn't happen until they were going to replace them anyway, to make way for more modern ATMs with more features.

On the other end of the spectrum, I was at a company some years ago that was built around Oracle 9i. At this time, Oracle 9 was going end-of-life and the company, in what can only be described as a knee-jerk reaction, decided they had to upgrade the entire system landscape to Oracle 10, Java 5 and whatever was the latest WebSphere (can't remember). Anyway, we are talking literally several thousand servers and systems. In the process of this upgrade, it was discovered that the existing hardware wasn't compatible with the new platform versions so the entire hardware park had to be upgraded. Since they couldn't take down the existing systems while upgrading and their datacenter couldn't fit all the new servers, a new datacenter was needed as well. I have no idea of the exact cost of this, but it was in the $100+ million range. All this because Oracle 9 was going "end-of-life". Was it worth it? Hard to say, no real benefit analysis was done so one can only speculate if not getting Oracle support was worth over $100 million and 6 months of IT not delivering anything except upgrade.

So I guess the moral is that never upgrade if you don't have to or if there is a clear economic incentive to do so. And remember to factor everything into the calculation. Things like increased efficiency/productivity in development is also a benefit that must be weighed and valued.

share|improve this answer
    
There are more worries for .NET developers who face these situations often. Next OS version stops supporting few things and asks for the latest .NET version to be installed for all their products. –  RPK Mar 13 '12 at 17:38
add comment

what is the criteria of upgrading an existing project to a newer version of the technology...?

The criteria is that upgraded deliverable successfully passes full testing, what else?

In my '2011 project, we successfully waived 2 or 3 "cowboy upgrades" using this criteria.

- Hey guys wouldn't it be nice if you upgrade Fuxis 1.5 to 1.6?
- Sure no problem. That will take about two months in testing, fixing regressions (if any) and re-testing. Do you want us to proceed?
- Forget it, it was just a thought.

At the end of 2011, we managed to release critically simplified version with lots of bugs fixed and much improved maintenance. Which is not surprising, taking into account amount of effort we saved by not messing with bells-and-whistles upgrades.


Is it advantageous to keep pace with the technology version?

As long as there's no concrete data on application usage, such a pace sounds like a waste to me (unless it expands my personal job/career opportunities but that's another story).

When there's data, it typically gets quite easy to find out if there is an advantage or not.

- Hey guys we want bugfix A and feature B.
- Sure no problem. That will require upgrade from Fuxis 1.5 to Buxis 2.0, which will take about two months in testing, fixing regressions (if any) and re-testing. Do you want us to proceed?
- Forget it, we can live without.
...
- Hey guys we want bugfix c and feature D.
- Sure no problem. Just like 20 other requests you submitted for last year, that will require upgrade from Fuxis 1.5 to Buxis 2.0, which will take about two months in testing... Do you want us to proceed?
- Yes please.

Above is not purely imaginary "scenario"; I've seen it happen at least twice in 2009-2011 in different projects and companies.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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