Developer

Risk management drives development tool upgrades

Many development environment upgrade decisions are made from more than just a cost/benefit perspective. Tom Mochal examines the real reason many upgrades are performed: the risk of being left behind.


Development tools are always changing and improving. They become smarter and do more things with fewer clicks from the developer. But how do you know when you should upgrade your development tools in the continual face of more and newer technology? Of course, not one answer fits every situation. There are a number of factors that come into play that each organization needs to consider. In my last column in this series ("When is it time to upgrade your development environment?"), I looked at the basic cost/benefit equation in upgrading. If there were no benefits, it probably would not make sense to upgrade at all. However, new technology usually holds the promise of greater productivity, in exchange for the cost of training, testing, converting and, in many cases, supporting the now obsolete older technologies.

Left strictly to a cost/benefit equation, I think there would be much less development environment upgrades taking place. For instance, how many shops have completed a thorough cost/benefit analysis on migrating to the .NET development environment? If you did, how compelling was the business case?

The chances are part of the business case not only involved cost/benefit, but also risk analysis. Many upgrade decisions that do not stand on their own from a cost/benefit perspective do make sense when you look at the risk. Let’s look at the real reason many upgrades are performed: the risk of being left too far behind.

Risks associated with obsolescence
When you are considering new technology, like .NET, the risk is associated with obsolescence. Basically, if you stay where you are, you need to understand whether the technology you have today will be rendered obsolete. The way technology evolves, products seem to have a built-in shelf life—kind of like cars. About 40 years ago, companies made fundamental decisions to move to a COBOL programming environment. About 30 years ago they may have decided to go with an IMS database. Today, those technologies are still workhorses. They are not sexy, perhaps, but they still power many of the critical business applications in use today. Sure, you had to upgrade them periodically, but the core capability is still there.

Think about the technology coming out today. Do you think any of the Web development technology that is in use today will be around in 20 years? It’s doubtful. The pace of technology change is much faster than before. COBOL was big precisely because everyone was using it. Today, the development environment is much more fragmented with products covering mainframes, midranges, PCs, PDAs and the Web, to name a few. Each platform and environment has a myriad of products and tools, and everything is changing. Today’s popular products could be obsolete in a few years as new platforms and tools are introduced.

So, the fear of obsolescence plays a big part in the decision to migrate to newer development technology and tools. For many shops, this is a fundamental driver behind a move to a .NET development environment. They migrate despite the fact that they may be happy with their current toolset, and they know there will be pain associated with moving to the new environment—from training to bug fixing to testing of your applications.

However, if you are sticking with a Microsoft-centric development environment, you know that the technology is moving down the .NET path. You also know that if you do not migrate at some point, your development environment will begin to become obsolete. Vendors typically only support two (or maybe three) old releases of their products. With new releases coming out every 12 to 18 months, you will find yourself without vendor support in three to five years. Another consideration is that the migration to .NET is not transparent. The migration will probably require new skills and changes to your existing Web applications. From that perspective, the longer it takes to migrate to .NET, the larger the skill gap you will have to cross in terms of training and technical competence. If you continue to develop in the older development environment, you will also have a much larger base of applications to test and convert to .NET.

It’s a pretty bleak picture. So, it is possible, and even likely, that the cost/benefit picture of migrating to a new development technology will not be compelling. However, you may find that the long-term risk of not migrating is a worse alternative than the pain associated with doing the migration over the short-term.

Decisions on timing migrations
Most companies are committed to maintaining a development environment that remains on a supported path that appears to be viable into the foreseeable future. However, there are still decisions to be made in terms of timing. When does it make sense to pull the trigger and actually migrate to new releases and new development technology? As we’ve shown, there is a risk associated with waiting too long. There are also risks associated with being one of the first to make the move.

Early adopters can gain competitive advantage. They can also be left holding the bag when the technology is not ready. This even applies to upgrades of existing tools. Many companies will not migrate to new releases until the vendor has released its second iteration, which usually includes bug fixes that were discovered by the early adopters.

Your risks are greater if you are an early adopter on new technology. There is a risk that the technology will not be popular and will not be sustainable in the future. If the vendor is new, there is a risk that it may not be viable in the future.

Skipping a release
Many companies take advantage of the fact that vendors put out so many releases by actually skipping every other one. Most vendors continue to support at least two, and sometimes more, older releases. This means that you can stay on your current release when the next upgrade comes, and not upgrade until the second major release is available. This strategy allows you to remain on a supported release path, while reducing the disruption and cost associated with upgrading.

I have often had discussions with developers who are interested in bringing in the latest and greatest technology. All of the technology promises to increase productivity and make life so much easier for the developer. I remember having this exact discussion when .NET was being released. However, the management decision to migrate is more complicated then just looking at the benefits of the new technology. There is also a cost involved. Short-term costs are associated with training, testing, and converting old applications. If you cannot migrate all of the impacted development applications, there is also a long-term cost associated with having to maintain legacy applications in the older technology.

In our case, as in many others, we made a fundamental decision to migrate to the .NET development environment. Sure there were proposed benefits in developer productivity, but ultimately there was a sense that Microsoft was going to be driving a .NET train for the foreseeable future. It was risky for us not to be on that train. But we didn't want to be the first passengers. We would leave that for the real risk-takers. However, we would not be laggards either. Ultimately, we would wait for the first release and the first set of major bug fixes before we would hop on the .NET train.

 

Editor's Picks