Where we stand

In the first part of this post, I discussed some of the issues web-oriented companies face when they decide to upgrade the software technologies they rely on, taking the example of updating our development framework from Ruby on Rails version 2.x to version 3. I highlighted issues linked to code deprecation, time consumption, evolution of programming practices (greater emphasis on JavaScript programming for example) or compatibility between old and new libraries. However, keeping up with technology is essential to improve the quality of products and services you deliver to your customers, and to make your life easier in the process. Therefore, I now want to propose a general strategy to go about these updates and describe key-points to consider before doing so.

Understand the update

It may sound dull, but make sure you understand what you are embarking on. Read the release notes, consult blogs, run some queries with your favorite search engine to get a general feel of what you are facing. Unless you actually are the edgiest company out there, there is a good chance that other people have suffered through the same process, and you will save valuable time and effort by reading about their mistakes and solutions. There are also valuable tutorials out there that usually make things look simple, but from my own experience, you will oftentimes run into environment-specific issues.

Know your team

When developing your update strategy, consider the members of your technical team. How savvy are your programmers? Do they have previous experience with the transition you are trying to implement? Do they have time to research and implement the transition plan? As stated before, major updates take time in training, implementation and testing. If you are a small company, it is unlikely that you have people solely dedicated to updating development and production environments. Furthermore, updates are likely to impact the way your programmers function, potentially requiring them to call upon/develop other skills. Rails 3 is a perfect example of this, as it puts more emphasis on the JavaScript development. If you have people that have experience with the update, I would let them test it on a simple application for a few days to see if they are up to the task. However, if you don’t, or if the update can potentially affect all your systems at once, I would consider hiring a consultant that will either perform the task or guide your team through it.

Assess the need on a single application basis

Let’s say your company developed several applications using Rails 2.x framework. Rails 3 is finally released and you decide to update all your applications. Before you do that, ask yourself the following question: what will Rails 3 bring to each of the applications we are currently providing? If you need to, build a spreadsheet listing your applications and all the features mentioned in the Rails 3 release notes. Assign some kind of weight to these features to help you determine their true value. An important aspect to consider here is the current development state of your applications. Are they in production yet? Do you foresee major updates or addition of new features that would not be compatible with Rails 2.x? Does the new update address major security issues? In the case of Rails, your applications will have to be updated independently, with an amount of code to rewrite proportional to their complexity. If you have an application in production that already performs well, is relatively bug free, and satisfies your customers without need for additional features, I would put it last on the Rails 3 upgrade list. On the other hand, you may have an application in development that has not gone through serious debugging and has not seen customers yet. In that case, update-related bugs can be fixed before affecting your clients and the transition will be much smoother.

Don’t forget about dependencies

Sofware relies on software. Web applications usually rely on multiple pieces that cohabit as symbiotic entities. I am talking about plugins internal to your applications, but also services such as Apache, Phusion Passenger, Webrick, MySQL and so on. In the best case scenario, you control all of them and can therefore spend time determining and testing the appropriate combinations before deploying the new set up in production seamlessly. However, in some cases you don’t, for example if you sell your application as a package to be run on your customer’s infrastructure. That means you will be hoping your customers don’t cringe when they realize they have to update their systems to keep on using your product. It’s a dangerous game to play and an easy way to make your customers unhappy.

Document and back the f… up

The title of this section should be quite self-explanatory. Before you go ahead with the updates, document your current configuration, and back it up. Document each step of the update, highlighting problems as they come, and solutions (and share it with the community if possible). Make sure you perform the update in your development environment first and test it thoroughly. Also, don’t forget, it’s not because it works fine in your development environment that it will in your production environment. So test, test, test and do your final upgrade at a time when the majority of your customers would not be affected by some down time.

Final words

Major system updates, which occur every year or two for a given technology, is a significant source of headaches for software companies. The pain usually being exponentially proportional to the size of the company. Updates, however, are necessary to stabilize your IT infrastructure, improve system security, provide new features, simplify development for your team, and improve the overall quality of products and services you deliver to your customers. In order to alleviate the suffering of keeping your company edgy, you may want to consider the following guidelines:

1) Know what you are getting into
2) Assign the right people to the right task
3) Only update what needs to be updated
4) Start with the simplest and safest solution
5) Understand your IT infrastructure as a whole
6) Document your successes and failures on the way

While these 6 commandments will not solve all your problems, they may prevent some frustration and hair-pulling. Good luck!

Read Can living on the edge throw you over the edge? Part 1: Looking down