Disclaimer: Security updates are, of course, an exception to everything I’m about to say
Increasingly I have the feeling that every software supplier in the world—from the maintainers of abstruse open source libraries, to the behemoths writing operating systems—want nothing more than to harangue me with endless calls for “critical” updates. As time goes on, I’m increasingly skeptical about the necessity to stay on the bleeding edge. The reason is this: Whereas updates sometimes bring improvements, they are guaranteed to bring change. And, as any programmer knows, software is allergic to change—all the more so for larger projects. I’m not saying software can’t be changed—of course it can—but I am saying the process can be painful.
This dread of pain explains why developers are forever pushing back against (relatively) unimportant changes suggested by non-technical stakeholders. This same reserved attitude ought to also apply to software version updates. Case in point: Every time I upgraded the major version of my Mac’s operating system, I cost myself at least a day in lost productivity. Previous installs of various programming languages no longer work. Hundreds of libraries—some of which require long compile times or awkward custom installation steps—break down. Subsidiary software tools like databases, code editors, or file-browsers need updating too, and that’s assuming the developers of these tools even have a version for the latest OS update. What’s more, sometimes even old configuration files or old data needs to be migrated for compatibility with the latest versions—I’m looking at you Postgres.
Beware of Auto Updates
Auto updates are particularly heinous. Because they happen on their own schedule, you might switch on your computer to work one day only to find that half your software is broken.
This leads me to my first rule: Turn auto updates and their pushy notifications off. You should only update software on your own schedule–not on Apple’s or Amazon’s. Because auto-update installation periods and their ensuing chaos effectively paralyse you, you cannot respond to bugs or urgent requests after one of these auto updates has occurred. This is absurdly inopportune if your web application happens to catch fire at that time…. you will be stuck there with your hands tied behind your back, staring at the spinning beach ball of installer death.
Keep (at Least) Two Steps behind Cutting-Edge Version Numbers
When you update to the latest version of a library as soon as it gets released, you turn yourself into cannon fodder, the front line in intercepting freshly introduced bugs. In some contexts, like the open source world, putting yourself in the line of fire is honourable, even noble—very much an act of charity toward a project’s developers and toward the community at large. Essentially, you have volunteered to be an unpaid human subject in a software trial during which you will be amongst the first to encounter, report, and (maybe) fix its bugs.
But there are downsides aplenty. For the immediate future, there may be bugs that hamper the functionality of your primary project. Even if the latest version you installed is totally bug-free, its documentation may be inaccurate in that it might fail to communicate that the API has changed. There will be no solutions to these problems on Stack Overflow. You, the software pioneer that you are, will be on your own. And all this costs time—time you don’t have.
This brings me to my second rule: Hang back. By staying a few version numbers behind the bleeding edge, you enable other, braver souls to clear the way. As a consequence, your eventual upgrade process will be far less painful and surprising than it would have otherwise been.
Let it be clear: I am not advocating that you continue running Windows 95 for the next forty years. I’m only saying that you stay behind the front lines and wait until the debris has been cleared before making your move. But, obviously, security updates are an exception.