A Good Example of a Bad Example

As most of y’all know, I’ve been kind of up in the OneDrive debacle for a while, going back to when the “new” OneDrive was only available on the Insider builds and breaking everything. But like everything that goes this epically wrong, there’s a lot others (and the OneDrive team) can learn from this epic situation

1. One Major Change At A Time
   One of the biggest things that’s hitting OneDrive Mac users is that there’s two fundamental changes hitting them at once. This isn’t new chrome or a slight reordering of things, OneDrive on the Mac has made two fundamental changes that affect everyone using the app. One of those, the moving of the OneDrive root was imposed on them via API changes from Apple. The other is the Files-On-Demand being no longer optional. My guess is the latter was in the works when the former hit, and rather than delay the FoD changes, they went ahead with them anyways, “may as well have all the pain at once.”
   
   Developers, if anyone ever suggests this to you, fight back as hard as possible, because this will cause you pain for years. Years. The real problems from the OneDrive root changes such as:
   
   Using OneDrive on an external drive is now a real problem, one that may not be fixable
   
   A lot of workflows that depended on those files being in a specific place are broken
   
   Backing up OneDrive files to other systems may be a problem depending on the backup
   
   The OneDrive root change alone will take months to sort out, along with any bugs caused or discovered. Throwing the FoD change on top of it was just foolishness
   
   
2. Beta Programs Are Not Enough
   If you read the forum posts on this, it becomes obvious that there’s a host of users that are being whacked by the OneDrive root changes:
   
   People with workflows that rely on files being here, not there.
   People using document/media management applications like Adobe Bridge
   People using database-driven apps like Devon Think
   
   There are a lot of apps and workflows that rely on files not being moved by third parties in the background. Heck, just scripting stuff relies on files not arbitrarily being moved or deleted. Yes, there’s the Insider Program, but that’s going to be a highly self-selected audience, which is going to lean IT a lot, because we’re the ones who need to know what’s coming down the pipe, and even then, not a lot. A lot of IT folks, for good or bad, don’t test until the final release. I think that’s foolish, but that’s me.
   
   In any event, even though I know for a fact that the problems people are seeing now were reported during the beta cycle, I think the team either blew off the data as “well, not that many people will be harmed by this” or pulled a New Coke, and payed a great deal of attention to the data they liked (“We think this tastes better than “old” Coke) and blew off the data they did not like (“But don’t replace Coke with this”) For example, for me, in and of itself, the OneDrive root changes are not a real problem. They’re mildly annoying, but they don’t break anything.
   
   For folks with different more complicated workflows, the OneDrive root changes break a lot of things. Like a lot. But if I’m more representative of the people in the betas, you’re getting skewed data that ends up being bad.
   
   
3. Major changes need a lot of warning
   The level of information people had about this at the start was slim and none, and almost all of it buried in MS Dev/Technical sites. That was stupid. Even if the only change was the OneDrive root change, that should have been way more publicly announced and talked about, with examples of how to manage those changes for things like OneDrive on external drives, Adobe Bridge and similar users, etc. It’s not like Microsoft didn’t have the money or resources to do this, they chose not to.
   
   Yes, I’m aware that notification doesn’t always work. Apple notified people about the elimination of 32-bit apps in macOS for over a year before it happened, with warnings happening on application launch. I know of at least one entire university whose IT team ignored those warnings completely, so for six months, Mac users who had updated or got a new Mac couldn’t use the school’s VPN client because they hadn’t updated their stuff and made the 64-bit client available.
   
   But people ignoring information does not justify not having it available. If nothing else, having the documentation available ahead of time makes it easier to direct people with problems covered by that documentation.
   
   
4. Make sure your support teams are well-informed of the change
   There’s really good data showing that the OneDrive team did not make sure the MS support staff were fully up to date on the changes and likely issues resulting from them. That borders on inexcusable.
   
   
5. Don’t victim-blame
   Don’t pull a Steve Jobs and tell them they’re holding it wrong. If someone has had their stuff working for years with your product, you make a change and they break it, and now they have to do a lot of work to get back to where they were, telling them they’re doing something wrong is a bad idea. It’s not their fault, especially if you didn’t warn them well.
   
   
6. Don’t Gaslight
   Telling people the new changes are really better for them and their objections/problems aren’t real or “there aren’t that many people who didn’t like the change”? Bad idea, very bad, almost guaranteed to motivate people to think hard about not being your customer anymore. Your opinion on the changes is not more important than the pain and work you’re causing folks.
   
   
7. Make sure your “solutions” aren’t more trouble than they’re worth
   This applies more to the FoD “Just keep clicking and downloading until it’s all done” coda. The level of anger created by making a customer do a lot of work just to get back to where they were three seconds prior to your change is not small. Ideally, the OneDrive team would have had scripts and other tools available to help make managing the OneDrive root changes and the FoD changes easier before the changes were implemented. That would have been a big help. Also, having the command line tools that would be a big help in remedying this actually work correctly and not be more work than clicking a hundred folders would have been a big help.
   
   
8. ONLY ONE MAJOR CHANGE AT A TIME
   Yes, I know, repeat. Enough people do this that a reminder is called for.

The OneDrive team got caught between the rock of API changes and a hard place of their own making. One I have sympathy for, the other…especially given the really bad response of the OneDrive team to the problems their bad decisions caused? Not so much.

Advertisement

Dealing with ‘new” OneDrive

So the changes that bit me in the tuchas in this post have come to production OneDrive, and I’m almost surprised to see my reaction was on the mild side. I’m not surprised, the forcing of FoD, aka “deleting a bunch of files from your hard drive without so much as a by your leave” was a shortsighted idea that on par with the decision to make the Oozinator and its infamous ad.

For the more technically astute, there are two technotes that apply:

https://docs.microsoft.com/en-us/onedrive/files-on-demand-mac gives you some tips on configuration, including the infamous /setpin switch, which in theory would allow you to better automate keeping copies of things locally. In practice, it’s awful to use, see my original post for my experience. Like really, it’s a dumb implementation, and that is the kindest thing I can say.

https://docs.microsoft.com/en-us/onedrive/deploy-and-configure-on-macos has more useful information, in particular the FilesOnDemandEnabled key, which can be set to off. The OneDrive team of course doesn’t recommend doing this. Right now, the effort involved in caring less about the OneDrive team’s wishes with regard to Files-On-Demand would be considerable, so I shan’t bother. Suffice it to say, their wishes on this issue have as much value to me as my turning off Files-On-Demand did for them.

To be blunt: were a random script or executable do what OneDrive is doing here, namely deleting data without so much as a warning, we would call that script malware and warn the world about it so suitable countermeasures could be implemented. That OneDrive gives you an as yet manual method to eventually get all the files that were already local back to that benighted state doesn’t change the malware-like behavior OneDrive is engaging in here.

As far as what I’ve seen from the OneDrive team on this:

We didn’t have many users turning off Files-On-Demand, this is not a real problem

The usage or lack of usage of Files-On-Demand is not the problem. It is OneDrive deleting large amounts of data without the user having any real warning about it, nor option to refuse. It is even worse for people such as myself who had turned Files-On-Demand off, and had OneDrive decide, “nah.”

We give you a way to still have all your files local

If I total your car while you’re asleep, and I pay for its replacement, you are still without a car for a non-zero amount of time. The fact that it’s not costing you any money doesn’t reduce the amount of time to get back to where you were before I totaled your car to zero. Same thing here. This also assumes that everyone using OneDrive has unmetered, high bandwidth (at least 100Mbps) connections to the public internet, and the time to restore potentially GB of data. 26.2GB in my case. Even with Google Fiber, that’s not zero time. There is no small amount of elitism and arrogance in that statement.

Apple’s API changes required this

They required you to move the OneDrive folder, they most certainly did not make you force everyone to Files-On-Demand, insinuating otherwise is quite insulting to your customers’ intelligence.

That there is still some method to undo this…nonsense does not make it zero bad, or zero damage. This needs to be fixed. There is nothing so amazing about Files-On-Demand that makes this decision worth the damage this has caused OneDrive, and I think it a shame that the team’s mindset comes from such a place of elitism and deliberate ignorance.