Customers give us a lot of feedback. We depend on that feedback to improve the quality of our products.
Since I joined our release management team 3 years ago, we have been operating with a mantra that our updates will improve the quality of the product over time. We continuously strive to make the product more stable, more secure, more performant.
At this moment the software updates business is at a crossroads. Where we used to have Patch Tuesday, and our working model was a rhythmic, slow cadence of small updates, we're seeing the emergence of frequent, large updates delivered to many of our computing experiences. The most striking examples are the rapidity of single or few-instance services which are continually updating and refining in response to feedback and incidents within the service, as well as the rich game clients that force you to be current with updates to log into the server and play.
This mode of hyper-currency has great benefit to provider and to consumer. In many cases the rapid update cadence is paired with an aggressive, Agile development methodology which forbids / reduces bug backlog. Thus the time from discovery to resolution can be very short if the backlog is of a manageable size. Fixing bugs delights customers. Doing it faster is a good thing for everyone.
Except...
In the case of a product like Microsoft Office (and perhaps we are unique or on a very short list of peers in this regard), we have hundreds of millions of endpoints, all at various patching levels, all residing in a specific context such as a business or on a particular hardware configuration, etc.
More importantly, however, the connection of Office to its ecosystem presents an even larger question when we consider updating. Unlike gaming clients or single-instance services, Office client applications are usually connected to line-of-business or 3rd party add-ins. Within businesses, this is more often the case than it is the exception.
Combining the diversity of the ecosystem with the complexity of the environments in which Office does its best work, we face some interesting questions in figuring the best approach to the new world of software updates.
Recently Jeff Teper was describing our intent to accelerate the cadence with which we deliver updates. As part of the Office 365 offering, we must consider how we are going to approach this problem for all of the connected client endpoints participating in the service. There are many questions and approaches to consider.
I am going to treat this post as an ongoing dialog on our approach. This post will grow over time - stay with it and watch it unfold.
When it is complete, I hope to have a full description of the factors we're looking at for a faster release cadence, the approaches we're going to enable, considerations our customers might weigh, and hopefully collect some feedback along the way.
Feel free to participate in the discussion.