The Upgrade Dilemma

If you are working on a project that uses 3rd party products you should be facing this dilemma regarding upgrades, regularly. It could be a core system upgrade such as .Net framework version or a SQL Server database version or a significant 3rd party component upgrade. Usually these upgrades proposals come from tech teams.

Assuming that cost of the software that is being upgraded itself is not prohibitive, most of the arguments are centered on the work that needs to be done by the team to stabilize the product with the upgraded version

Arguments

1. Arguments in favor of the upgrade

a. If we don’t upgrade now, when would we upgrade? After we acquired another 1000 customers?
b. It would be an incentive for the developers. It will help with both hiring and retaining good developers, since they tend to want to work on the latest and greatest.
c. We could get rid of some of the nagging bugs in the product, as the new upgrade solves them
d. New upgrade contains significant and important changes and we should take advantage of them
e. If we are up to date with the latest version, our product won’t become obsolete

2. Arguments against the upgrade

a. There aren’t many useful features in the new version
b. Everything works now so why should we unnecessarily disturb the code base?
c. What is in it for customers, since they didn’t ask for the upgrade?
d. If we upgrade component A, component B will not work
e. We will need to test the whole product, which would be very expensive. We might miss some parts which can put the product at risk
f. The whole process could be exhaustive and we may burn out the team
Most of the arguments against the upgrade are centered on changing the code base, and the fact that changing code could be a risky affair. However, I usually favor staying as current as possible, because the speed with which new upgrades are being released to the market is extremely fast, and if we fail to stay current, the product will end up becoming stale and will almost certainly require a big rewrite in the future.

Process – What Not To Do

Upgrade by committee

It is very tempting to gather all parties involved and conduct formal meetings, get all of their buy ins, create and manage a project plan. This means lot of meetings, follow ups, emails and creates inevitable creation of heroes who will end up taking on the bulk of the work to meet some arbitrary deadline. It may sound logical, and works most of the time. But this is a very expensive process, and usually involves lots of meetings. These meetings are the breeding grounds for “Fear, Uncertainty, Doubt (“FUD”). Any one person in these meetings can derail the attempt or significantly delay the process. After one such upgrade experience you will lose the appetite for any future attempts.

Process – What To Do

If you are really looking ways for successfully convince the organization or your boss for an upgrade here is a summary of what worked for me.

1. Build confidence

Your organization must have faith in your team. They should believe that your team can deliver. They should know that you can fix issues fast and that you care about the success of both the business and the product. This won’t come in a single day. You need to build that confidence every day. One trick that works is to constantly solve simple problems. These kinds of problems won’t take much time. They don’t need big project plans. They come from all parts of the organization. Solving them proves that you are for continuous improvement.
Try to tackle troubled areas of the products. These are the parts of the software that attract frequent bugs, frequent code churns. Try to take initiative and make that area trouble free. Once you successfully solve such problems, you are guaranteed to gain the support in any of your future upgrade proposals.

2. Build safety net

If you don’t have them already, you should start writing tests for important areas of your application. These tests when written properly help you in two ways. They help you identify the problem quickly and also help serve as a repository of business knowledge. You must run these tests with every code check-in.

3. QA is your friend

The most important help you can get from you QA team is in the form of exploratory tests and also from testing tedious, non-automated parts of the application. A tester with an intention to solve the problem is the best resource than a tester with an intention to just report a problem. Have them involved in every non trivial decision your team makes.

4. Research

If the upgrade is going to have big impact on your product, wait for about 6 months after the release date of the upgrade. Go through the release notes, breaking changes, write small prototypes to test the areas of the concern.
Most importantly go through the product support forums to understand the quality of the version you are upgrading. Even if you decide not to upgrade, this research helps you decide the future direction of your product.

5. Build excitement within the team

Try to lay out the broad plan for the upgrade. Take your team’s consensus. Understand possible real problems. Tell them why the upgrade is important. A self-organizing, motivated team can make the whole upgrade process a trivial affair. As a team, you should try to think through and anticipate every major problem, and come up with possible options. Consider other major projects your team is dealing with to make sure that they are not being unnecessarily burdened. Come up with a possible time line.

6. Sell the proposal

Get the major stake holders in a room and sell your proposal. If you did your homework properly this should go well.

7. Appoint a facilitator

Find someone in the team (a PM, BA, team lead etc.) who can act as glue with all the team members. Their job is to continuously update all stake holders (management, team, end users etc.) about the team’s decisions, choices and find answers.

8. Short but to the point standup meetings

Meet twice a day to talk about the most important issues that you team is facing that day. This helps the team to share the work, gather questions, seek answers and inform stake holders about problems.
I too often here developers complaining that their organization is not good at keeping at the top of the latest technology trends. I believe that this is mostly due to the lack of effort from the software teams themselves.