There is risk with upgrading anything, be it language, framework, library, OS or third parties.
In the past I was rather gung-ho about upgrading. New version out? We need it. In fact, this need is often a want. The new version often seems better. Developers seem addicted to the latest and greatest.
One of the best, but also one of the worst problems with software development is weekly there is something new to use or try. Keeping pace is impossible.
Internet Echo Chamber Effect
If you look at a news article on the release of something, you feel as if you are the only person not using it. Everyone is is using it, we need to as well.
In fact this is quite the opposite case. A site about the latest web framework will seem as if everyone is using the framework apart from yourself. This is known as the Internet Echo Chamber Effect.
Wait for a Patch
Wise advice I received and saw others follow was the minor or patch adoption. If version 2 comes out, wait for 2.1. Let others find the issues and wait for the version to stabilize. If you really must use version 2, use it in a low risk way. Personal projects or in house solutions make sense. You can keep pace but reduce risk in this manner.
Boring but Stable
Another approach is to take widely used, stable solutions. Avoiding anything new or cutting edge except for personal projects or internal projects.
If your job is to write software to sell widgets, focus solely on that, what you use behind the scenes really doesn't matter. As long as you can delivery value and aid the sale of widgets you're on track for success.
A similar alternative is to use boring solutions for anything that has high risk. While using newer, more exciting solutions for low risk projects. Again risk is managed and reduced. If the new, cutting edge solution becomes the norm, eventually you can adopt this in the future.
A younger, less experienced self would not find this advice at all appealing. After all if the tests pass why can't you upgrade to the latest and greatest? The main issue is risk, which will be the subject of a future post. Every single change, be it a single line of code has risk.
The one exception to this advice is security concerns. If a security release is available you should aim to upgrade as soon as possible. Usually such releases form minor releases, meaning risk is low and matches the delayed upgrade path above.
- Any change has risk.
- Reduce risk when handling new technology.
- Either use stable versions or boring solutions.
- Play and test new technology on the side, in low risk scenarios.
- What technology you use to build something actually doesn't matter in most cases.