Bug Alert

Office FeatureGates: How Microsoft Can Break and Fix Their Applications in Under 24 Hours

Microsoft Access regularly breaks following Office updates. But, sometimes, it *starts* working again just as suddenly. Here's how that works.

Mike Wolfe

• 4 min read
Office FeatureGates: How Microsoft Can Break and Fix Their Applications in Under 24 Hours

"Move fast and break things."

It's the Silicon Valley mantra.  And it seems to be all the rage in Redmond these days, too.  

How Dost Thou "Break Things"? Let Me Count the Ways

It seems like every month or so there's a new bug that affects Microsoft Access.  Here's a brief sampling from just the past six months:

"...break things."  Yep, they've got that part figured out.  How about the first part?

The "Move Fast" Silver Lining

If there's a silver lining in this, it's that Microsoft has invested time in recovering from bugs.

With a monthly active user base of 10 million or so, even the corneriest of corner cases will appear almost immediately when a new feature is rolled out.  Automated testing helps identify these types of bugs, but it's not a panacea.  The bugs are still getting through.  I mean, just look at the above list!

However, if you click through to those articles, you will find that many bugs get resolved within a day or two.

So, how can Microsoft fix a bug in a new feature without users having to wait for the next monthly release?

FeatureGates: The Magical Fix

When Microsoft rolls out a new feature, they do it in such a way that it can easily be rolled back without having to ship a program update.  

So how do they do that?  Here's the official Microsoft explanation:

When we ship changes we always try to wrap them in something called a ChangeGate or FeatureGate. This is how we can contain the impact on any change on customers as soon as possible if it breaks something unexpected. Basically when an office app loads it requests statuses of these gates from the network, to determine if the code its wrapping should execute or not. That way if the new code causes a regression, we can change a setting on a service on our side and when a user restarts the app the issue should be resolved.  This is how we can contain the impact on any change on customers as soon as possible.

Et voila!  

Microsoft flips a switch on their servers and misbehaving features get turned off.  All you have to do is close and reopen your application to make it work.

And how do you know if such a fix exists for the problem you are having?  And if you know such a fix exists, how do you know if it's been applied to your software?  Or the software of your 100 closest friends and colleagues if you are an IT admin?

Here's the best part.

...

Wait for it.

...

You don't!!!

A Magician Never Reveals His Secrets

The FeatureGate approach is a brilliant solution to a difficult problem.  

It shows that Microsoft has invested time and resources into minimizing the impact of bugs.  But it suffers from a fatal flaw:

The FeatureGate system is completely invisible to the end user.

I'm sure this felt like a feature at Redmond, "Hey guys, no one even has to know there was ever a bug in the first place.  If we roll it back fast enough, we can deny it ever existed."

OK, that's overly cynical.  And in defense of Microsoft, that's not how I've seen it play out (at least with the Access team).

I'm guessing the more likely explanation is that there are lots of these feature gates.  I can imagine a monthly feature update rolling out with dozens of feature gates for every application in the Office suite.

A Modest Proposal for Transparency

While I would love to see a "settings dialog" or something similar that showed the status of all those feature gates, I can think of several downsides:

  • It's one more thing to maintain
  • The average user would be overwhelmed
  • It would generate a lot of tech support questions

Instead, I offer three different proposals.

Add a /FeatureLog Command Line Flag

Running msaccess.exe /featurelog "C:\Path\To\Feature.log" would create a file named feature.log that would include:

  • Full version and build information for the application
  • Bitness
  • Install type (click-to-run vs. MSI)
  • License status (trial vs. perpetual vs. active subscription vs. lapsed subscription)
  • Licensed features
  • A list of all the feature gates and their values (on/off)
  • A list of applied hot fixes

I'm imagining this as a tool that could be used on Access forums to help assist users that are having trouble.  It could also be incorporated into an automated error log.

This would be my preferred approach, but it's probably not realistic.

Add a /FeatureGateStatus Command Line Flag

Running msaccess.exe /FeatureGateStatus 54132 would emit "Disabled" or "Enabled" to standard out.  The same command line flag could be added to every Office application.

Add a FeatureGateStatus.exe Utility

Modifying every Office executable to support a new command line is probably not realistic either.

Instead, Microsoft could provide a small command-line utility that would do the same thing as the /FeatureGateStatus command line flag.  Here's some sample usage:

C:\> FeatureGateStatus.exe msaccess.exe 54132
Enabled

The idea behind these last two solutions is that we in the community need some way to be able to tell users whether the problem they are experiencing is caused by a broken feature or not.

There needs to be some sort of explicit action a user can take to tell them whether a bug will affect them in their environment or not.

Image by anncapictures from Pixabay

Never miss an article.

Sign up to receive a Sunday morning email with links and recaps of the seven articles published that week.
(I'll never sell your email. Unsubscribe any time.)


Enter your email
Subscribe

All original code samples by Mike Wolfe are licensed under CC BY 4.0