Have you recently updated an app your computer or your smartphone (or accessed your favorite Web app), and been faced with the arrival of:

1. New features out of the blue
2. Changed behavior for existing features
3. A release that removes or breaks a feature you frequently use
4. A user interface change that completely modifies the way the app works?

If so, you might be a victim of mutually assured distraction (MAD). MAD can also alternatively be referred to as competitive cheese moving. 

Once upon a time, software companies released software on semi-predictable schedules, with a modicum of cheese moving. User interface elements might have been moved, but users familiar with the application (or sibling applications) could find their way around with some degree of ease.

However, with the arrival of milestone-driven and Web-based software, we increasingly find ourselves facing a world where applications we are comfortable with and used to are rapidly, somewhat inexplicably, shifting on us (quick apps?). Faced with increasing competition and the agile software approaches used by competitors, more and more (and larger and larger) software companies are pushing out software that’s sort of done, sort of usable, and sort of documented.

Mutually assured distraction allows company A to volley out a marketing message when they hit their milestone and release, only to be responded to when company B (and company C, D, ad nauseum) releases it’s own milestone months or weeks later – and the process repeats. With each milestone burp of a release, little nuanced changes in the software arrive, and it is up to the end user of the software to figure out what changed, if the implementation of their favorite checkbox feature from company B works better than the implementation of checkbox feature from company A did a month and a half ago. Or if it’s still even there.

The problem with MAD is the position it puts end users in (not to mention the organizations/employers that still support them, as these applications still often have to be used for collaboration between two or more employees – that is, people have to get work done).

Adding “value” all the time may seem like a boon for the end user. But it really isn’t. It makes understanding the features of the application as it exists today hard enough, and the reality is that no end user has the neurons available (or desire) to keep track of all the changes coming in the application. They just want to get things done and use software and hardware that just works.

It’s one thing when you add a completely new feature that doesn’t really shift the way the app works for end users. It’s something else entirely when you remove or modify functionality that users depend upon and are comfortable using. When you do that, you’re violating a cardinal rule of building software:

Don’t shit on your end user’s desk.

Yes, it seems simple enough. People don’t like surprise. They don’t like it when you move things around just so you can say, “Look! We changed things! We improved it! LOOK AT THE VALUE YOU’RE GETTING!!!”

If you’re going to make your development milestones visible to end users, you darn well better give them some clue about what features you plan to add back (and ideally, some timeframe for when you plan to do so). For me, I think that this increasingly industry-wide move to faster and faster releases of key software applications creates an unsustainable cadence where users can never be fully productive with the application, and anyone responsible for supporting, deploying, or licensing applications for them is in for just as much pain, or more.