I love technology. But in this series on technology that sucks, I use hyperbole for entertainment and to point out areas that have stalled out. Stalled technological progress sucks.

Synchronization of information between devices sucks.

• It shouldn't be necessary. When we add synchronization, we admit a design failure or limitation elsewhere.
• Synchronization is provided by myriad special services with diverse behaviors and capabilities. At best, this is confusing, and most likely frustrating.
• Its prevalence grows as we use more devices. We are irked by synchronization more than ever before.
• Synchronization is often not built into devices and applications, rather it is made available through third-party add-ons. It's often the domain of power users only.

Consider synchronization abstractly. The idea is to copy and merge state information among multiple contexts. With state information omnipresence, my appointment calendar is available to me on my phone, my tablet, and my two desktop PCs. My contact list is available when composing an e-mail. My browser bookmarks and open tabs are always the same.

It should not be necessary

Bear with me here. I know synchronization is necessary to accomplish state omnipresence given the way devices and applications work right now in the real world.

But stepping back from where we are right now and remapping technology resources, applications should exist to perform work for users and be available consistently—with their state information intact—from any device.

When we add synchronization to our life, we are coping with a design failure. The failure is that we have two or more applications that do the same thing for us. Hence, we need to synchronize state between those applications.

Applications should be single instances that are continuously available to their user with a consistent state available from anywhere and from any device. I call this theoretical model "Personal Application Omnipresence." It's a theoretical model—it doesn't exist—but I feel it should. Rough approximations can be hacked together, such as by combining RemoteApp with RDP Shadowing. But since no applications are designed with PAO in mind, no applications respond to varied input/output (UI) contexts in the way responsive web sites do today.

I want PAO now. For every application I use.

I don't want multiple applications. I don't want a Twitter application on each of my desktop PCs, another on my tablet, and another on my phone. That breeds synchronization or frustration, or both.

I want a single application that is viewable from each of my devices. With a single application instance, state synchronization is simply not necessary.

Today, in the real world, state synchronization is used by power users because what we actually have is this situation:

Actually, to be clear, we don't even have that because efforts to provide full state synchronization for Twitter are fairly immature or abandoned, such as the Nest project that was planned for Rowi and MetroTwit. As far as I can tell, nothing came of it.

Synchronization is special and fickle

Because synchronization is rendered necessary by today's plain cloud services, countless synchronization products and services exist. Each solves specific synchronization needs—files, documents, bookmarks, e-mail, settings, preferences, music, etc. And each provides its synchronization capabilities with proprietary functionality, proprietary storage, and proprietary protocols. Best case scenario: a few vendors within a space agree to a "standard" synchronization protocol that shares the super-set of their products' state information.

Imagine you and I developed Twitter applications (okay, of course we wouldn't do that thanks to Twitter making third-party applications a dead-end, but humor me). We decide we'd like to synchronize state information between users of our two clients.

• Do we synchronize the information using a server we set up?
• Or do we come up with a (probably glitchy) peer-to-peer protocol?
• Do we try to synchronize through the Twitter servers using something sneaky that they won't notice or won't mind? (Good luck!)
• Do users have to pay for the synchronization capability? Someone has to run those servers.
• What do we synchronize specifically? The timeline "read" position? All of the visible columns? Preferences? An in-progress tweet?

Even if you and I come up a way to synchronize every piece of state information used by our two applications, and our implementations are bullet-proof, we can't anticipate all of the possible state information a third application might want to synchronize.

Our protocol is special-purpose to our applications.

Let's step back: why two applications?

Again, the root problem is that we assume a user wants to use two separate Twitter applications. So we aim to minimize the pain suffered by the user of two applications.

I argue that no user wants to use two different Twitter applications. They do so because that is simply how today's cloud and today's applications work. Even two instances of the same application is still two applications.

And the worst part is that in reality, synchronization is fickle. Some synchronization tools work better than others. So in the real world, synchronization often fails.

When implementing synchronization, the protocol designers and application developers need to provide failsafes such as a resynchronize function and possibly a combination of incremental, wrap-up, and full synchronization. Maybe they need to deal with merge conflicts and devices that come back online after a month-long hibernation.

Synchronization is hard. Not so hard that it can't be done. But hard enough that it's often implemented poorly and the user needs to babysit. It sucks.

Every added device compounds pain

We love portable computing. Every hot new device brings joy to our lives. We can interact with friends, colleagues, and the Internet as a whole from anywhere. But as I recently explained, portable computing also sucks because every additional device comes with a dose of pain.

The pain is multifaceted. It's another batch of applications to install and attend to. Another disk to store data on. Another unlock password. More vendor-specific cloud services aiming to help us solve these pains by adding friction. Another set of notifications.

I recently picked up a Surface Pro. I love it for what it is. But I also hate it for a simple reason: it's another computer I need to deal with in my life. Do I install MetroTwit and have yet another Twitter client telling me I have 200 unread tweets because it doesn't realize I've been reading those tweets on my desktop?

Every additional device is another synchronization node. Will we be able to find the right plug-ins to make our new tablet or phone work with the e-mail we have configured and are happy with on our other four devices? Or do we just concede, "I don't bother with e-mail on that device."

Notifications are especially annoying with the plain cloud and synchronization. When I receive a Skype message, I receive it at my desktop, on my Surface, and on my phone. I even receive it on my workstation at the office since I leave that on all the time.

Receiving the message in multiple places is fine, if a little silly. (The many chime sounds make me laugh. Beep, beep, beep!) Each device is on and we don't yet have the technology to allow each device to know whether I'm "present" at a different device. (Though that would certainly be easier with PAO: you are simply present at the last device that sent any input to any application.)

The truly annoying part is dismissing the same notification in multiple places.

Often, third-parties provide synchronization

Sometimes synchronization is provided by a first-party—the application vendor. This is usually the case when the application in question is available for a variety of devices and synchronization is a core feature. Evernote, Office 365 (assuming you login with Microsoft), Google Chrome (assuming you login with Google).

Even when synchronization is a first-party service, it's often tied to that party's cloud offering. Friction again.

But sometimes synchronization is a third-party service, meaning a plug-in or separate application. Think of the host of bookmark and tab synchronization add-ons for Firefox. The incentive for third-parties to provide synchronization is simple: you want the pain of multiple devices reduced and they want your money.

But every time I see a synchronization service, my head hurts a little bit. Why must I synchronize everything in my life? I want one instance of each application, one file system, one address book, one calendar, one list of notifications. And I want those things to be provided by applications that I run personally.

In the news

If you look for it, technology news repeatedly tells us that synchronization sucks without actually saying so in those words. Consider today's popular article, Embrace, extend, extinguish about Google Reader and RSS.

Pay attention to how much pain is manifested by the desire to synchronize information about what you have done with your RSS reader(s). If only authors of RSS readers didn't need to choose between developing a synchronization protocol or adopting a protocol provided by a capricious third-party like Google.

Consider how Google Reader extinguished other RSS readers in large part because it is a cloud service so it doesn't really need synchronization. It's a web application, so it's available anywhere you have a web browser. But it also relies on centralization at Google's data center.

Third-party web applications like Google Reader are not PAO; they are omnipresent but not personal.

Update on 2014-02-13: CNet reports that Skype finally fixed its long-problematic message synchronization problem. Delivery of messages is a core feature of Skype and it failed to do so reliably for at least a year. In part, synchronization sucks because it's error-prone and not easy.

Previously and next

I have a few other points about synchronization (such as the challenge of dealing with varied device capabilities) in the PAO article.

The plain cloud dominates and synchronization tenaciously irritates. A chief reason for this situation is the failure of virtual private networks for consumers. My next rant: VPNs suck.

Final notes

In some contexts, synchronization is used for resiliency and is therefore simply unavoidable. For instance, on the server side, a load balanced web application might be designed to synchronize user session information between servers so that any given server can be taken offline without affecting users. This post is about synchronization as it directly affects consumers: between devices. For consumer devices, resiliency should be provided as federated backup of the master file system, not by spotty synchronization.