Let’s look at your phone for a second. Do you have the newest model? If not, you probably know someone who does or who’s waited in line overnight to get the newest release.
Maybe you don’t need the newest phone. Maybe you got a new phone six months ago, and it’s still working exactly as it should—maybe not as well as it did on day one, but with little to complain about. But maybe you’re a few years (or more… we won’t judge) behind, and it’s showing. Maybe it’s time for an upgrade. But which phone do you get—the newest model released last week, or the one released last year?
It’s the same story for upgrading your hardware and software. The benefits of keeping your software and hardware up to date are numerous—new features, bug fixes, faster processing, better support from manufacturers, and so on. But just how up to date do you need to be? When should you be at the bleeding edge, and when should you take a step back?
On the Bleeding Edge
Being on the bleeding edge is appealing. It means you get access to the latest and greatest, the coolest and shiniest new features as soon as they’re released. It gives you a competitive edge by giving you time to get used to the product, learn how the features work, and integrate with your other hardware and software.
But when you upgrade to the bleeding edge, you have to ask yourself: do I really need the newest cool thing right away? Will this work in my environment? Introducing the newest technology can introduce problems—first, there’s likely to be a huge learning curve, as with anything new. But also, it simply being new can bring problems—the new device or software hasn’t been tested in an environment exactly like yours.
Let’s say you’ve done testing. You’ve put the bleeding edge device into your lab or demo environment, and everything runs smoothly. But your demo environment is a microcosm of your production environment. If you’re lucky, your demo environment will have one of each type of hardware and software (that your company knows about) in production. While the code might be similar, it’s not going to be an exact duplicate. Folks are adjusting the code in response to things they’ve seen in production, or maybe it’s all homegrown. In any case, the risks of being on the bleeding edge cannot be ignored.
Just the Right Amount of Up to Date
If you don’t want to be on the bleeding edge, you still shouldn’t be too far behind on releases. I consider responsibly up-to-date to be one version behind the bleeding edge. When you’re one version behind, the software or hardware has been tested and the bugs worked out. By waiting for a service release, many of the initial problems are fixed, and things generally run smoother. Do you have the new, shiny toy right away? No. But you still get the new shiny toy, after those on the bleeding edge have tested it in larger environments—maybe even one similar enough to yours.
The downside here comes with support. Say you run into a bug with your responsibly up-to-date system and you need to contact support. You’ll most likely be told to upgrade because they found and fixed the bug already. Nobody’s going to write a custom patch for you—upgrade to the latest version, and you’ll be fine.
Where Should You Fall?
Whether you’re on the bleeding edge, responsibly up to date, or elsewhere in your upgrade cycle, you have to accept the responsibility for it. You’ll need to tell your boss why you don’t have the shiny new feature—maybe you’re up to date, but the feature they’re asking for came out yesterday.
My best advice for anyone on the fence about an upgrade is to listen to the communities. (The
THWACK® community is a great place to start.) There are always people out there keeping on the bleeding edge, and by holding off, you can see how the latest and greatest is working for other IT pros and decide what would and wouldn’t work for your environment.
In the end, every environment is different, and you need to do what’s right for your company.
