Development tools are always changing and improving. They become smarter and do more things with fewer clicks from the developer. They are more intuitive in how they work. They have also become more visual and now allow you to construct more and more code at a higher level of abstraction.
How do you know when you should upgrade your development tools in the face of newer technology? Of course, not one answer fits every situation. It hardly ever works that way. However, a number of factors come into play that you should consider before making a decision.
Three types of upgrades
There are a number of scenarios where upgrades come into play:
- Incremental releases of the same product: You may have to decide whether you should upgrade from release X.Y to release X.Y+1. These point releases are fairly common. They normally include minor functionality improvements and bug fixes. They typically do not have much impact on the environment, although they must be tested to make sure.
- Major release changes of the same product: These occur when a product is upgraded from release X to release X+1. Sometimes these have little impact. Other times the vendor introduces a substantial number of changes in a new release. At the extreme, the new release may not be compatible with older releases.
- New development tools: The last case involves actually migrating toward different technology and tools. In this scenario, you are making more fundamental decisions, such as switching database vendors, moving to a new platform, or adopting a new programming language and environment. These kinds of changes really need to be thought through in the areas of short-term and long-term costs and benefits. In general, these upgrades are disruptive in the short term.
I recently had an upgrade decision to make. Our group was doing Web development using a typical Microsoft set of tools. One of my developers came up to me one day and said that we really needed to consider migrating to the .NET development environment. At that time, the .NET set of development tools was not even released yet, and so I did not have to worry about making any short-term decisions. However, I knew that once again I would need to make some decisions about our development architecture and when to make changes.
There may be some overriding factors that require you to always be at the cutting edge of new development technology. These business factors may mean that you migrate to the new tools early, perhaps as a beta site for the vendor. However, the rest of us usually have some time to make decisions. Ultimately it boils down to two steps: a cost/benefit calculation and a risk assessment.
My experience is that upgrading your development environment usually provides long-term benefits and short-term pain. If you cannot convert all the older technology, you will experience long-term pain as well. However, there has to be some benefit before you would want to upgrade the environment. This could be a short-term benefit that you can measure right away, or it may be a benefit that you will see over the longer term. Examples include:
- Increased productivity: Typically you migrate to new tools to achieve the Holy Grail of development—faster development times. Tools do more and more of the mundane programming work and allow the developer to work faster, with fewer errors. It is very difficult to measure the productivity increase exactly, but speed of development has definitely increased over time.
- Cost savings: Better tools allow more development to be done by fewer developers. Sometimes the new tools themselves also cost less than the older ones.
- Morale: I think using new technology (or at least keeping fairly current) keeps people motivated and interested in their job. If your development technology is obsolete, some people will feel as if they are getting left behind and may consider leaving your organization.
There is no question that migrating to new technology involves expense. These costs include:
- Conversions: Many times when you upgrade your development tools, the business applications written in the older tools need to be converted. Conversion requires short-term pain and costs. However, if you do not convert, you will have the long-term costs associated with supporting and understanding two technologies. The cost of conversion may, in fact, be prohibitive in the short term. When I worked at a Fortune 100 company, we always had one standards development environment. The problem was that the development environment changed every couple of years. Over time, the result was a huge mish-mash of differing development technology and tools. This situation made the development environment very complex and difficult to support. Yet, at any given time, the cost to migrate away from these older technologies was prohibitive.
- Testing: You always need to test, even if you are just updating to a new release of a current development tool. This includes understanding the capabilities of the new tool, installing it in a development or test environment, and then testing all the affected applications to make sure everything behaves as expected.
- Training: There may not be a training issue when you are upgrading to a new release of a current tool. However, changing development tools usually involves training costs. You might also need to bring in contract people who already have the skills in the new tools to help your staff become productive sooner.
- License costs: Again, if you are upgrading an existing technology, there may not be license fee implications. However, if you are getting new technology, you may have to pay license costs for the new tools while continuing to pay license costs for the old tools as well.
Sometimes the benefits associated with a new development technology are so compelling that your organization decides immediately to utilize it. However, many decisions are not so black and white. In fact, in many cases, the real cost associated with upgrades and migrations cannot be justified when compared with the more nebulous productivity benefits. Why then do we continue to upgrade and migrate the development environment over time? In particular, why will a large percentage of Microsoft development migrate to .NET? The answer lies as much in long-term risk management as it does in cost/benefit analysis. While this column looked at the cost/benefit equation, the next column in this series will look at the risk management aspect.