The other day I started my car, A Ford Escape. The dashboard computer system is a Microsoft Sync which was a colossal software failure in its own right, which is an article for another time.

Anyway, upon turning on the engine, the SiriumXM app fired up yet another update. During an update, you can't listen to satellite channels or even see your audio console at all. Sure it may only take 2 or 3 minutes to complete. But in a five minute drive to the store, the SiriusXM is more or less unusable.

I'm absolutely aware of what a non-essential problem this is. It's not even a "white person's problem" but more of a "idly curious, bored person problem." The point is that these updates happen in the car slightly less than once a week. Personally, I drive my car a little less often than the next man, so my car radio starts in update mode about 10% of the time I'm on the road.

It got me to thinking: How often should you put out software updates?


Security vs. Functionality Updates

Let's get this out right off the bat: Nobody in their right mind would or should complain about security updates to software. When a vulnerability is discovered, it has to be fixed and code updated ASAP. Every time.

A great (and painful) example of what happens when security patches aren't taken seriously enough is with the Equifax breach. This article is a brutal indictment of their slow response. Actually, Equifax did respond and have a patch ready to go - they just didn't deploy it. Oof.

But functionality updates are significantly less timely. What we mean there is that they are feature improvements, new features, bug fixes and typo corrections. They don't have to be out the door the moment they are coded.


Patch vs. Update

When considering software updates, it's useful to be clear on the difference between a software "patch" and an "update". We can define a patch of being a revised snippet or subsection of the software being sent to end users, as opposed to the entire app (or operating system) being updated.

For instance, when Microsoft puts out security fixes for Windows vulnerabilities, they send out a patch. When you click on the button to accept it, the patch just modifies or replaces a few files - not all of Windows.

Another way you can think of a patch is that it doesn't really change the functionality of what you see. Whereas an update will have something visibly different about how the app, program or website runs.


Things To Consider

On the software development end, there isn't a magic formula for how often you should push out updates to users. A short rule of thumb would be to make sure the improvements are, in your mind, worth it. Here are some things to consider that might help dictate how often you need to package changes and publish updates.

What Updates Require Of End Users - Can you package it to be one-click or do they have to download then run the upgrade program? Will this tie up their computer while install is being done? Is a Windows reboot necessary for the update to complete?

Does It Disrupt Any Data? - This is a huge no-no. There's an absolute expectation from 100% of people using software is that an update will not lose or corrupt any of their work or data. Test this during your development. And when you're done, test it again.

Option To Delay Updating - My SiriusXM example from the top of this article was a case where I did not have an option when to update. Yes, that's often the nature of embedded systems like car software. Whenever possible, give users the ability to choose when they can update. If you don't, they tend to resent the timing.

Rollback Option? - Yes, you shouldn't be pushing out software that will fail - and would necessitate a roll-back. But in our experience, we've seen apps that didn't work as advertised in a particular environment. In those cases, having a failsafe has been a life-saver.

Testing - In all honesty, this whole blog post could be about how essential testing is in an update. You cannot take software that works fine for your customers and then push out an update that will spontaneously break the software. Also, you can't throw so many new features, new forms and new looks at users. People get efficient in using your software over time. Don't cross them up.

Importance Of New Features - If you have a game-changing new feature, or a fix that lots of your customers have been clamoring for, then you do want to get this out there as soon as possible. But if your changes in a new version are some typo corrections, a fix to a rare problem, and a couple of other things that users won't notice then perhaps you should hold onto that update for a few months and when you do push out a new version it will have another 4-6 months-worth of solid but unspectacular changes.


Pencils Down

OK, let's stop here. Next week in Part 2 I’ll share some things we’ve learned from experience about how often to update.