The Control-Alt-Backspace Upgrade Strategy: Software

This is part two of a two-part series on my strategy for when and how to upgrade hardware and software for maximum effectiveness and minimum bother. Last week we talked about hardware; this week we’ll move on to software, which needs a completely different strategy.

Goals

Almost everyone will agree on the following three goals for software selection, though we may prioritize them differently:

• Have software that works for as large a percentage of the time as possible. Working can be tricky to define, but working software has at least the following properties:
  • It helps you accomplish the task it’s designed to do.
  • It doesn’t suddenly get worse at that task or stop performing its usual functions.
  • It doesn’t expose you to security vulnerabilities or data loss.
• Working software is nice, but good software is even better. So if software gets better due to updates, we’d generally like the updated version.
• Spend as little time and/or money on software research and updates as possible.

Traditional practice would have you believe these three goals – and especially the first two – are, if not diametrically opposed, at least in an ongoing feud. I argue that, for the most part, it just ain’t true anymore. It might have been true back when new software came on discs in the mail once a year after you paid your upgrade fee, but the Internet and new development methodologies have upended that reality. Whether your primary goal is having working software or getting the best new software, one approach helps you get there in today’s world: upgrade promptly.

So, if you want to take my word for it, you can close this article right now and just go update your software regularly. If you want the reasoning behind my perhaps surprising recommendation, though, read on.

Why is software unlike hardware?

My strategy for hardware advocates a conservative approach in which you upgrade devices as rarely as reasonably possible while still meeting your needs. Why not do the same for software?

Let’s start here: unlike hardware (and most everything else in the world), software is not subject to scarcity. It’s written once, then it can be distributed essentially for free over the Internet, and it isn’t lost and doesn’t degrade when it’s transferred, so millions of users can get exactly the same software, bit for bit. Copying software consumes no limited resources (aside from incremental and barely noticeable amounts of electricity), and updating most software nowadays doesn’t even cost money. Therefore, it makes sense to consider a different approach to software that takes this useful property into consideration.

Note: Of course it isn’t really true that software isn’t subject to scarcity; it’s still part of a finite world. It’s just that the systems that run software (which do have to contend with scarce resources, and which in fact are quite expensive both financially and environmentally) make the incremental cost of dealing with each single software change vanishingly small: once the world has put the Internet and the data centers together and you’ve bought your computer and your Internet access – which is a given at this point – a single software download is a statistical nonentity. Whether we can maintain these supporting systems to the required standard in the face of ongoing and increasing resource depletion remains an open question in my view, but for the moment we can ignore these issues when considering software, as the life cycle of software is sufficiently short that those outcomes make no useful difference to our decisions today.

No upgrade fees

I am assuming that your software doesn’t charge an upgrade fee. Charging for each version of software used to be the norm, but in the last ten years or so open-source, free software has become far more common, and most companies that sell software have found it’s easier and more profitable to support just one version of the software at a time, offer free upgrades, and use one of the following business models instead:

1. Charge a regular subscription fee.
2. Distribute the application for free or cheap and include advertising or supplemental in-app purchases.
3. Just charge once and assume an ongoing flow of new users (e.g., some popular mobile apps).

If you do have an upgrade fee to deal with, your software becomes more like hardware, and you may need to modify this advice.

Unfortunately, many users and managers are still stuck in the scarcity mindset even when there’s no upgrade fee and no scarcity. The classical upgrade strategy is to wait until the current version no longer meets your needs, then go acquire and install the latest version – as if it were hardware. Admittedly, this strategy often works acceptably. But we can do much better!

Just update

A better strategy involves taking every upgrade promptly when it’s available. You don’t have to do it right away, and I don’t recommend “auto-update,” because this function has a knack for kicking in at exactly the wrong time and breaking your working software installation when you can least afford it. But as soon as you have a few minutes to spare and an upgrade issue you have to stop to resolve won’t cause you to miss a deadline, the update-immediately strategy has you take the upgrade.

Why do I think this strategy is better? Well, as a general rule, actively developed software gets better over time. We can find plenty of exceptions, sure, whether because significant new bugs were introduced or the system was “redesigned” in a user-unfriendly way. But even these instances of software worsening on an upgrade tend to be resolved after another version or two (consider the amount of whining that has transpired as Facebook has updated its website over the years: nobody would seriously claim today that the Facebook of 2008 was better, even though everyone complained at many steps along the way). And in the vast majority of cases where the new version is incrementally better, you start getting the improvements right away instead of waiting for weeks or months. Think about it: supposing the software literally gave you 50 cents per day after you upgraded, rather than merely saving you that much in productivity, would you rather upgrade now or three months from now? That shouldn’t be a hard decision!

Even if you look at the list of new features and bug fixes and don’t see anything you care about, there may still be useful changes. Bugs could be fixed that you don’t even know about yet but that would appear in the next month if you decided to put off upgrading. New features you don’t yet need might prove important soon.

Many people worry that upgrading means the software will change and they’ll have to relearn something. Sure – but when you take every upgrade and the upgrades come frequently, the amount of change in each individual upgrade is tiny. Unless it’s a particularly large upgrade, you usually don’t even have to go read a manual or release notes, you can just figure it out as you go along, maybe wasting a minute or two once when you encounter something that’s changed. Some newer software will even pop up a little tutorial box when you use a feature that’s changed. If you wait for months or years while all the changes pile up, when you finally do upgrade, work comes to a standstill while you relearn everything, to the point that you may be further discouraged from taking the upgrade even when you really need it!

But most naysayers accept those arguments, then say that upgrades are risky and they’re not willing to take on that level of risk: every time you take an upgrade is a chance for something bad to happen. Yet not upgrading can be just as risky: many upgrades fix security vulnerabilities or data integrity issues that could cause you to lose work (or worse, your company’s reputation), and these are common enough that you won’t always get special advisories when they’re found. Plenty of software nowadays will also stop working sooner or later if it’s never upgraded, due to operating system changes or servers being shut off. And you’ll have a hard time getting support from the authors if you’re ten versions behind; then instead of just fixing the straightforward problem you’re having, you also have to take a big upgrade.

Beyond that, most of us are scared of upgrades and have bad experiences with them precisely because we don’t do them often enough. That may sound absurd, but the more often we upgrade, the less trouble we’re likely to encounter. You’re far more likely to encounter upgrade-related bugs when you jump many versions at once: more things are changing, and your exact upgrade scenario may well not have been tested at all, given the number of possible version jumps to test, whereas any half-competent developer will always thoroughly test the upgrade from the most recent version. Smaller upgrades therefore mean a better-tested path with less to go wrong. Further, if you do run into trouble, it also tends to be easier and faster to solve the problems or revert to the previous version with a smaller upgrade.

Obviously if you upgrade your entire computer two hours before you have to give a presentation to 500 people, you’re taking an unnecessary risk. That’s why I recommend turning off auto-update so you can pull upgrades at a convenient time that works with your schedule, instead of whenever the computer decides to. Updating manually also means that when something suddenly stops working right afterwards, you can be reasonably sure that the update is at fault and know how to start fixing and/or reporting the problem. If your software updates all by itself without telling you, you might think you’re going crazy when a button disappears or you start getting a new error. But a “convenient” time doesn’t mean “next year”! I try not to put mine off for more than a week, two at most.

In the event that something actually does break – because it won’t happen often, but eventually it will, no matter what upgrade strategy you use – it’s rare that you can’t easily revert back one version. (In the cases where you can’t, such as an upgrade made by a third-party website, you usually can’t control when updates happen in the first place.) If not, a quick call or email to support, whether commercial or community-provided, will likely get you back in business. What’s more, companies and individuals that release their software on a rapid schedule tend to be responsive to customers and users in general. If you take the time to report an issue with the update, especially if you have enough technical knowledge or experience with the software to provide a detailed explanation, you may find the issue fixed within hours or days.

Staying up to date is a solid investment in the future that sometimes even helps in the present, and just taking upgrades when they show up reduces your need to make minor decisions. Just quit worrying about whether you should upgrade and stay up to date.

Tip: If you’re particularly risk-averse, waiting a fixed period (say, 10 days) after each release and then taking it can be a useful compromise strategy. That’s usually enough time that other people will have identified and the authors will have fixed any really serious bugs. Unfortunately, no standard update tool I know of allows users to specify this kind of policy and see updates only after that time has elapsed, so the bother of the manual tracking involved here can outweigh the marginal benefits the strategy offers, unless you’re willing and able to write your own tools to track the updates.

Caveats

• If your software puts out gigantic updates on a slow timescale, the developer of that software is operating in scarcity mode (and it’s a bad idea for them too). In this case, you have no sensible choice but to follow them. Fortunately, this model has been slowly dying for years in many industries.
• Sometimes even software that generally offers fast, incremental updates needs to release an upgrade that breaks compatibility with the previous version and changes a bunch of things all at once. You’ll want to treat this upgrade with caution – not as cautiously as true hardware since it likely still comes with no additional cost and not updating leaves you vulnerable to bugs and security issues – but still cautiously enough to read the documentation for any gotchas and plan out a good time in the next couple of months at which to take it.

What about changing tools?

Here’s where we go back in the direction of hardware. Jumping between tools anytime you see something that looks slightly better often makes your life worse instead of better. Every time you use new software, even supposedly “free” software, you have to pay the up-front cost of finding, installing, learning, and customizing that software. And after all that, you may find it’s no better than, or even outright worse than, what you were previously using! Updates rarely change the software fundamentally, so most of your learning and customizations can be preserved. New software usually has some kind of fundamental changes, so this work must be redone.

Thus, my recommendation for changing tools is to stick with what you’ve got unless you become dissatisfied with it – just like hardware. When you do, cautiously explore the Web to see what other options might be available. If you don’t see anything that looks better, then you’re done for another year or two. If you do, try it out, and give yourself a chance to back out after doing some basic testing and learning without investing a whole lot. Only once the results are still promising is it time to commit to a new tool. Your most valuable resource with software is nearly always your time.

But meanwhile, keep investing in the tools you are using by upgrading them!