Adding a Feature to Media Center

On that last post there was a good conversation about DIVX. I'd like to expand on this a little bit to help explain the process we go through in determining what features go into the product.


For the sake of the rest of this post we’ll just talk about a Codec named FOO (that way it is clear that I’m not talking about DIVX – because I’m not).


If you were a program manager on Media Center and your area was playback this might be something you’d be worried about. So let’s follow the product cycle in a bit of detail.


The first thing you’d do would be to define the problem:


Media Center's Customers need FOO built into the product and into all Media Center Extenders. FOO is a primary file format for watching videos and is a significant adoption blocker for Media Center.


Step One: Figure out where we are in the product cycle. If you look below I talk about both M0 (planning) and DCR (Design Change Request) phases in a product cycle. Things are very different for each phase - but for the sake of this example we’ll say we are in the planning phase. This means you have time to both design and “sell” your idea to include FOO.


Step Two: Spec out the solution. This is really the research phase. A spec, in my all too humble opinion, is to answer all questions about your feature. This would not only include what the user interface and interaction would be like – but also background details and market info.


A spec on FOO would likely contain information that would detail (in no specific order):


  • Research: Customer need, number of customers affected, type of FOO content, licensing rights (can we even ship the FOO codec) future MS plans, etc. Do our partners (OEMs, etc) want the FOO codec? Could there be a business reasons that they wouldn’t – if they had their own competing codec? How would you install it? How would you build it? Can we check into our source tree?

  • Costs: How much time would it take to write the code, test the code, develop help, explain the features

  • Scenarios: All the ways a customer might use the FOO feature. Can you burn FOO? What would it take to enable that? How would you get to the content? Would it be shown in the Videos or TV area? How would you ensure the proper decoder wasn’t removed? How long should it take to load? What about other countries? Can you use FOO worldwide? Is it compatible with all TV standards? Will the remote control be able to run the FOO playback? What about fast forward and rewind? Would this be smooth and a consistent user experience? This list can go on and on…

  • Schedule: When will the work get done? Is there time? How much would it cost to write the code? To test it? Do those teams have the resources to do the work?

  • Ranking: How does the feature rank against other features that the development team has? More important then TV playback? Less important than photo slideshows?

  • Feature Flow: What does the user interaction look like? Would you denote in the UI that you were playing a FOO file?

  • Long Term: What if there are bugs after we release? Can we fix them? Who would do that work? What would a patch look like? How could we build it?

  • Reviews: Once you have all the above data (and more) and you’ve written into document form so everyone can understand it - you need to review it with your peers and managers. More changes and questions always come from these reviews. You would also review a test plan here and make sure that your test team is ready to test your feature and has the content types to do it properly. Here you might also find that management cuts this feature because of the cost of other features or because of a change in priorities. There are usually several reviews.


After all of the work is done you might find that even with the reviews and data the feature comes in after something more important and gets cut.  You might find that the test team doesn’t have time to do the work or enough people. For the sake of this post we’ll say you get this nice long document written and everyone buys off and you get your feature approved. Woohoo!


Well not yet. You haven’t started developing.


Step 3: Development


Here you would continue to work on the project. Get early beta feedback. Understand how the feature is being used. See if there is more work that needs to be done.


There is danger to your FOO codec work here as well. It might take longer to code. A DCR ( might come along that is more important.


Step 3a: Test Planning


As the development team is writing code the test teams will be working on test plans. The goal here: Break the Product.


Think of this as spending time figuring out all the obvious and obscure ways the FOO codec feature could be broken. Does it pause properly? What if I hit pause and play thirty times really fast? Can you control it with only the remote control? Can you use only the keyboard? What if you are playing music and then go to the FOO codec? What if you have a bad FOO file? Again the list can go on and on…


Step 4: Testing


When the code is complete you finally start testing it to see how well it works. Here again is another area for danger. We might find the code too unstable to keep. There might be other areas that need more coverage for an emergency problem so the FOO work is left behind. This would mean that bugs wouldn’t be found in time to be fixed and the feature would be cut…


But you make it through testing and voila – your in the product…well almost.


Step 5: Product Cycle


The most nebulous step in a product cycle. Anything can happen here – and usually does. Your feature could be done and working well – but the FOO codec company pulls out of your legal agreement? Or everything is scaled back because of a change in focus.


Usually you’re okay at this point – but there are always fire drills, last minute changes and possible problems.


All right. That was one very, very brief overview of what it might take to get FOO into Media Center. Be aware that I really reduced the issue down to the basics – and went into very little details.


Each step in the process and each sub area for the spec could be an entire book. I’m happy to expand on any of these areas – so please let me know.


Finally you’re probably reading that thinking about all the structure and hoops you’d have to jump through to get such a small thing as the FOO codec into Media Center. Seems like a lot? Well it is – and for good reason. Each and every feature you see in Media Center goes through this level of scrutiny and is subjected to this rigor to help ensure that the UI is consistent and the experience is consistent.


Two thoughts come to mind at the end of this post as to what you might be thinking:


  1. “But you still have bugs. How can you still have bugs? You’ve done all that work” Good question. We’ll talk about that soon.

  2. “How can you ever get anything new into the product if you have to do some much?” Another great question. I hope this blog will work to answer that…


See you in the comments…

Comments (31)
  1. wise azz says:

    So much for Foo, but what about Divx??? (typical consumer reaction) Just kidding — couldn’t resist.

  2. Travis Owens says:

    Going back to the original statement, being DiVX, considering the tone of this article, I don’t expect to see DiVX support in Media Player.

  3. MSDN Archive says:

    You guys are funny. Please don’t read any DIVX into this. I have no clue about DIVX support for any of our products. I’m hoping to shed a little light on the question, "Why didn’t Microsoft just do feature X?"

    Take DIVX out of your minds. Even I wanted to comment on DIVX I don’t have any data.

  4. avidgator says:

    This calls to mind the important story of the birth of the PC – how IBM had become so beaurocratic that an internal analysis revealed it would take 9 months to simply ship an empty box, and that to breakeven (if I rememeber correctly) they would have to sell the box for $1500 or so…it was only by breaking out of the beurocracy that thier Boca Raton facility (which is now sadly abandonded and overgrown) were able to introduce the PC.

    It is an interesting tug-of-war between being able to be responsive and having to be responsible.

  5. MSDN Archive says:

    I’ll need to read the article. Looks really interesting.

    This is really a struggle both for myself and the people who work here.

    I feel I you need to allow people to innovate (and encourage this) but you have a lot of customers to please and a schedule to meet. A tough balance.

    There are certainly people who like process for process sake. I’m not really one of those. I look at process as a way to ensure people are successful. I don’t need to know every detail – but I want to know enough to get a handle on what you’re doing and why so I can balance. Process by iteself is quite uninteresting – but process to frame growth is quite interesting.

    I worry about this more then I probably should…

  6. Aaron says:

    What about politics? What would be the reaction if a product manager assigned Divx support as a very highly ranked feature of an extender product? It sounds like a plausible scenario, assuming product managers are aware of what the market really wants (more codecs in extenders).

    But am I wrong in assuming that politics would stand in the way of us ever seeing Divx support in an extender (even though everyone and their brother wants it)?

    I have two extenders (Xbox, Linksys), and I can’t think of a more requested feature than better codec support. Actually, HD streaming is up there too. Damn you for making me buy one of those cursed Xbox 360’s with the awesome graphics, integrated MCE experience, wireless controlers, 802.11 support, oh and the streaming HD. Damn you! </sarcasm>

  7. Matthew says:

    Great summary of the process – demystifies it. Between your blog and Scott Berkun’s book (which is excellent, btw, thanks) I’m getting a clearer picture of how things are broken down.

    Step 3 "development" – provided that the specification is complete and functional, is development generally a "straight line" – or do you find that a sizable amount of time (say 30% for example) is spent circling back and modifying spec to match the "actual."

    What would you say (in Media Center projects) is the balance? Is there a lot of process recursion or is that intentionally saved for the testing phase?

  8. MSDN Archive says:

    Per the question on politics. I certainly think politics plays a part. At the risk of towing the corporate line – I’d say passion plays an even bigger part.

    If you have a very passionate advocate for a feature, and that advocate is savvy enough there can certainly be an impact.

    I don’t think politics would stand in the way. Really you’d see much more with business priorities and relevant data. The feature might be highly relevant – but it might not be a priority for the team.

    That’s where I say passion can help educate people on the team about the feature and the request.

    On the question from Matthew – I’d say that once a spec is written and locked you don’t see a lot of changes. There might be some circling back – but more likely you’d see a spec get out of date.

    This is one of the problems we face. We want developers to be creative (as software development is in essence a creative task) but there also has to be direction. Because there is collaboration between development, program management and test in the planning phase you see less of this then you might expect. However I think there is always a degree of deviation.

    For Media Center – we’re usually on a very tight schedule. Recursion is really focused on front loading (thus the M0 planning phase) – but there is always some. Too much and you will shoot yourself in the foot.

  9. MrLoopy says:

    While I understand that that is how things are currently done, it must be time to do a DCR on the actual process. How can other competitors (and just, well, others) bring out changes to their products in a much shorter time frame? Look at Google, mobile phone makers and DVD players with their firmware updates, TiVo with new features, etc. It’s funny, but I posted earlier today on TGB asking why MS MCE team can’t release features on a feature by feature basis? Why does it always have to be big bang, major update approach? Why can’t new features and bug fixes be released as soon as they are completed instead of waiting for release windows (no pun intended). I think, David, that the project managers think that these are the hoops that HAVE to be jumped through in order to release a product, instead of thinking about how to streamline the release to public process.

    Of course, I’m not a developer, but I did use to be a strategy consultant and the biggest reason most of the companies I worked with failed to innovate (or solve their problems or whatever) was the answer was always "this is the way we’ve always done it."

  10. MSDN Archive says:

    I tend to agree on MrLoopy’s comment. I’d like to see us do more about faster updates.

    I also think that it is right to say, in a sense, that we are not structured to do this as we speak. Really our teams who are working on shipped products are in sustained engineering. There is enough work to keep up on, let alone make feature changes.

    I also think the complexity of Office or Windows app is much larger then a web app. There are enough interdependencies that you will run into one update breaking another.

    For reference on that look up "DLL Hell" sometime:

    Now I don’t think by any means that this the big bang release is a perfect model – and I think the idea is interesting. More than I’d expect other companies to do, Microsoft is good at changing the way things are done internally to work with market changes.

    I think Media Center does address this a bit with the Online Spotlight area – but again not the whole solution.

    I also find the announcement we made today interesting about web-based applications.

    One other thing to note: Windows is also a corporate operating system and from personal experience there are things that can’t change – or rapid change would break their systems. I used to own a component that couldn’t change very much at all. We once made a change that broke a national rail system. Can you say rock and hard place?

    I love features as much as the next person (I really love features) but our model doesn’t support the rollout of features yet. Bottom line though is that the suggestion is not without merit and I think the company recognizes that..

  11. MSDN Archive says:

    I wanted to add one more thing to my last comments.

    When rolling out features on a feature-by-feature basis it could be hard on our development community. When making changes to APIs or DLLs that developers in our community depend upon it can break their apps.

    I’d also say feature by feature rollout is alive and well in the developer ecosystem for Windows and Media Center. There are lots of apps and extensions for Media Center and that is growing.

    Having worked in the developer division I really believe in the importance of a vital development community.

    All in all, without data, I think there are more applications and features written for Media Center and Windows daily then there are for most websites.

    My revisionist gut feeling says nail the platform and the development tools and the features will come.

    But I sitll do agree that it would be nice to be able to rollout more features from MS regularly.

  12. Roger says:


    That helps *alot*.

    I can’t help but think that there may be additional factors in your ‘Research’ phase.

    Obviously, there must be some consideration for ‘Strategic’ direction. If producing "FOO" is counter to the general plan the company has, does that allow that type of feature to get quashed early on? Even if your competitors are including a feature, that’s never *really* been a reason unto itself. Microsoft has a vested interest in moving the technology a certain way, and even up against an industry leaning in another direction, often it *appears* that Microsoft would rather stay the course than provide a more …universal… solution.

    Now, *recently* that appears to be changing. Office will output PDFs, and from the looks of it, provide OpenOffice filters for importing OO.o XML documents. That is the best news I’ve heard in years, as that indicates a shift in thinking around there.


    (1) Do/Can politics/strategic vision outweigh customer requests?

    (2) What kind of offical forum is there for bringing new requests. I’m still having to resort to guerilla blog-attacks to get questions answerd 🙂

    (3) Is the mindshift in the Office group company-wide?


    as always, your humble servant


  13. Stuart says:

    Good explaination of how things are done, but as has been said above there is one step you missed out

    0) FOO blocked on principle by Corp as they can’t be seen to support a codec which is primarily used by video P2P at a time when they are desperately trying to negotiate to let the PC be a carrier of securely DRMd content with Hollyood and the TV companies.

  14. James says:

    I’d like to know who submitted the DCR to have the CGMS/A and COPP mechanisms "revved up" in the latest update, and where would a submission like that come from inside of Microsoft? The legal department? Marketing department?

  15. MSDN Archive says:

    On Roger’s comment

    Strategic vision can certainly play a hand – and those visions can change.

    Best I can say is that there are times we are told what to add and there are times we come up with ideas. It happens both ways.

    As for the mindshift from Office going company wide I can’t really say. I will say that our developer division is very focused on this area of being open and collaborative with the community.

    I’d love to see Media Center doing something like this:

  16. Tim says:

    "When rolling out features on a feature-by-feature basis it could be hard on our development community. When making changes to APIs or DLLs that developers in our community depend upon it can break their apps."

    Now then, there’s this thing I’ve heard of for dealing with that. What’s it called? It lets you version your APIs, and maintain compatibility with old programs in a standard way.

    Damn, what’s it called? Tip of my tongue.

    Oh yes – COM. Perhaps you’ve heard of it? 🙂

  17. MSDN Archive says:

    Jokes are running wild here. This is fun. 🙂

    I’ve heard of COM and of this little thing called .NET.

    But I think you get my drift. Changes to the platform come with risks to the development community.

  18. James says:

    The whole process is kind of sad when you look at the big picture, and especially sad for you guys as programmers. A process like this kills innovation. It relegates a huge block of Microsoft’s programming ability to maintenance workers for each piece of software. Ideally, instead of being the programmer or company adding "FOO" to their own product, you’d like to be the programmer or company that created FOO in the first place. But how can that happen when any innovative idea has to work its way through a five-step program determining that the idea won’t affect anything else the company makes and won’t step on the toes of anyone the company deals with?

    Imagine if Bill Gates, at the infamous meeting with IBM back in 1980, had told them he needed to first submit a DCR for Microsoft BASIC and their request for an O/S didn’t fit the current product cycle…

  19. Finn Johansen says:

    How can a MS project manager, one month before launch, *not* know if XVID/DIVX will be supported by the media part of the Xbox 360.

    Easy answer.. "He cant…"

    All features for a product has to be finished way before launch.

    So I’m sorry. As my personal opinion, I can only conclude that one of the major video formats will be unsupported by Microsoft.

    The "jumping through hoops" to avoid answering dosent just cut it for me. I dont care if its because of company politics, DRM whoes or development problemes that XVID/DIVX is not supported.

    The conclusion, for my part, is that The Media Center Platform will not meet my needs and will therefore be irrelevant for me. That dosnt mean that Ill not buy an xbox360. Ill just not use it for my media needs or I will just wait for a modchip so it will meet my needs.

    And Ill reccomend the same thing to all my colleagues, family and friends. Why buy a "broken" product?



  20. MSDN Archive says:

    Simple answer to your question: well two of them really.

    1. I don’t manage the XBOX 360 and only used one for a short time.

    2. I didn’t check for it when I did….

    Simple enough?

  21. George Handlin says:


    This is an aside, but if you didn’t have pci xpress available, only AGP, what video card would you recommend? Was looking at the ATI x800 or 850, but am very open to suggestions. I want a good experience, but don’t want to buy a new machine yet.


  22. Matthew says:

    James question: "But how can that happen when any innovative idea has to work its way through a five-step program determining that the idea won’t affect anything else the company makes and won’t step on the toes of anyone the company deals with?"

    I think it takes a good project manager, and excellent communication at every step of the project.

    I think that startups w/ 10-12 person teams innovate fast because they’re a startup w/ a 10-12 person team. Much more difficult w/ a company like Microsoft where a single "group" can number in the hundreds.

    As a result, I think these projects are divided up into component parts and assigned teams to execute. I think you may be right in that it’s not always possible for a team to "innovate" if the agenda of the heirarchy is inflexible and conflicts with the agenda upon which the innovation is based.

    So communication is really critical, having a strong PM is critical, and making sure that feedback loops are utilized very early in the process is critical to voices getting heard.

    But at the same time, I think there’s something unique about the mentality of a startup. I hear so many programmers say "I wish I could get my pet project off the ground" – and I’m sure that there are a lot of them at MS, and it represents a huge pool of untapped talent and ideas.

    How do you get people to innovate? By taking them out of context. Incubation programs do this. If a bunch of programmers at MS want to do something, then they should be able to submit a proposal and get approval for a 2-3 month incubation "sabbatical" to execute it. Upon completion, if the project’s a success, then MS explores ways to take it market or incorporate it with an existing product, if not, the team goes back to their usual routine.

    David- anything like this happening today at MS?

  23. MSDN Archive says:

    On the video card question – anything with 128meg of VRAM, but I’d focus on memory speed. Of course 256 would be even better.

    Per Matthew’s response to James – that is a good response. I’d say comparing what Microsoft was in the early ’80s is like saying that you wish the road system was as simple as it was a hundred years ago. It just can’t happen. The many competing ideas need a way to get from here to there.

    Traffic might be worse – but I can guarantee that it takes less time to travel across the county now then it did then. Without some sort of structure everything would grind to a halt. Something has to get everything traveling in the same direction.

    Maybe not the perfect analogy, but a start.

    On the second part of Matthew’s question – I’d just say take a look at the sheer number of products that are coming out of Microsoft and the number of features in those products.

    Best example is XBOX. That was just a few guys who thought they could do a great game console – and proved that they could.

    We do spend a lot of money and time on research. Something in the billions of dollars.

    I’ll talk more about creativity in my next post.

  24. Tephlon says:

    Ok. So I’ve been reading along, and understand all of what’s been going on, and although im unsure if an old post will get rechecked for a response almost a month later… I figured I’d give it a shot anyways.

    So I’ve got a simple question. "FOO", as you said, is not necessarily divx and should not be considered as such… but if I read correctly "FOO" does represent a codec of some sort.

    So my question comes… why can’t the media extender treat a codec like any media player does (MS or otherwise)? Why can’t it go look for the approprate codec via the MCEPC? Or the internet, even? If the PC has it, why can’t it stream/copy/etc, the codec to the extender give it the power of the MCEPC?

    I understand all the process of ADDING the "feature" to the media center itself requires alot of testing, resources, beurocrocy, etc, and I’m even ok with it not being natively supported. But if I can download and install any codec onto my pc and have Media Player use it to play a movie, why can’t the extender too? I don’t expect any support from Microsoft on a product that isn’t theirs, so I don’t see where the major overhead on MS’s part comes to play.

    Is there just simply no easy way through software to tell the extender "Hey, go grab the codecs from the Media Center PC you’re ‘extending’." Is there simply no storage medium for the extender to place such codecs?



Comments are closed.

Skip to main content