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 (https://blogs.msdn.com/david_fleischman/archive/2005/10/24/484219.aspx) 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…