Building Windows Live

Comments withdrawn.

Responding to comments

Hello –

Thanks to all for the first round of comments.  As I said in my previous post, this is the start of a two-way conversation intended to discuss how we build and operate our services. We love all the comments and suggestions and we’ll read every one.  I’ve responded privately to more specific issues raised in the comments, and I will respond publically to others, but there were some general trends that seemed quite important, and most of these relate to the purpose of this blog and what type of topics we intend to cover here.  The purpose of this post is to set expectations for the responses you should expect to get depending on the type of comment that is posted.

As I mentioned at the beginning, we will “dig a little deeper into how we build our services and how they’re used worldwide” and we dedicate it to “software engineers, web industry insiders, and to our most passionate Windows Live customers.”  As a result this blog is about the products and services we have in use today, as well as additional detail about new releases as we roll them out.  As such, there are many types of questions this blog intends to answer, including what’s the architecture for the mail system, how many photos get uploaded every day to SkyDrive, how do we detect and prevent SPAM, and what are we doing about SPIM. 

Most of your initial comments center around three other areas – the schedule for the “next release,” feature suggestions, and feedback on “shipping sooner.”  Because these will probably come up quite frequently and have the same general answer I thought I’d take the opportunity now to write up our response and frame the general approach.

The first category are questions about the next release of Windows Live, including the future direction and features for Windows Live.  As a general rule, we will only discuss these as we near the release or availability of product updates.  This blog is not intended to be a breaking news blog, but rather a blog that provides an engineering perspective that details the work behind the product, our implementation, and our decisions.  As a result you should expect we won’t comment specifically on those questions.

The second category are feature requests.  In most cases, we will not respond to these directly, and instead we will note these down and consider them alongside all the other feedback we receive. When we decide whether to fix an issue you’ve reported or to add a feature that you’ve requested, naturally we have to weigh factors like how much work will it will take to get this done, how will that impact all of the other features and fixes on our current schedule, how many customers will benefit versus how many would benefit more from putting those resources into a different feature, and all the other tradeoffs that are made in the process of developing products. Often we get competing requests where some people say “add more features” and others say “keep it simple” and as a result we can’t say “yes” to everything.  Our goal of course is always going to be to create the best possible set of products and services for users, but it’s always going to be a complicated equation to figure out which features get priority in getting built, and naturally, we can’t promise anything until we’ve built it and tested it, and know that it is going to work on a global scale.  As one commenter pointed out (using different words) often when we respond too soon the response feels empty. So while you are free to comment with feature suggestions, expect that we will note these down as we would other suggestions and ideas and consider them with the other feedback we receive, and that our response will be coordinated with the delivery of updated software and services.

A third category of comments relate to ship schedule and shipping more frequently.  As with any project, there is a balance between frequency of updates (how often do you release), size of updates (how much change do we release at one time), and retraining (how much existing customers have to learn with any change).  Each project or team has its own balance.  Some products ship “every day” and make small changes, others take longer to ship, and make larger changes.  And often, projects change based on the needs and requirements of customers.  In the end we need to balance all of these into our overall schedule, including what we intend to accomplish, how long we think it will take, and the expected customer benefit.  There are certainly folks (and many commented on this blog) who would like to see us ship “sooner” and “change more.”  There are others that we hear from in other forums who “don’t like change” and want us to “keep things as they are.”  And then there are the questions of which  features we pick and how long those will take to be delivered with quality.  In the end, I’ll simply say that we are generally happy with our release rhythm and we recognize as well that our customers and competitors continue to innovate, which increases the importance of planning well.

I hope this helps to frame the blog and our goals in this discussion.  Thanks for taking the time to read and comment.

- Chris




More...