I’m Just A Feature

I grew up with “Schoolhouse Rock,” a series of short educational cartoons that played between the normal Saturday morning ones.  They were cute, set to catchy music, and taught us things like grammar and history, etc.   One of my favorites, “I’m Just A Bill,” gave a somewhat sanitized view of how laws get created in the United States.
 
I’ve been seeing a number of comments lately that basically say, “Here’s a feature request.  When are you going to have it done?”   Thinking back to “I’m Just A Bill,” I decided to do a blog entry that explains how features get done here in the Windows Mobile group.  It’ll be kind of a modern Schoolhouse Rock piece, just without the nice music or the clever cartoons or … well, okay, it won’t be anything at all like that.  But, while not as entertaining, hopefully this will be similarly educational.

The Easy Way

In my spare time, I write a lot of little applications for my Windows Mobile devices.  For instance, my son was learning his multiplication tables, so I wrote a Math Quiz app for him and handed my Smartphone over whenever we had time to kill.  Part of the fun of being able to write apps for your phone is that you can say, “I wish I had this,” and then make it happen.  But the real fun is that writing quick little apps is nothing at all like real software development.  I banged out a fully functional MathQuiz app in an hour and a half, tested it a bit, and then gave it to him to use.  He suggested some things (you haven’t lived until you’ve taken feature requests from your eight year old), I spent another hour adding the things he wanted, and that was that. 

Unfortunately, software development is rarely like this.  The only reason I could get away with such a pain free development cycle is that my target audience was extremely small.  Windows Mobile, on the other hand, has millions and millions of users.  Developing something for one or two people is easy.  Developing something for millions of people never is.

“What” is harder than “How”

Since 2000 we’ve shipped six major releases and countless minor ones.  Here’s a newsflash for you:  there will be a Windows Mobile 6.  And a 7.  And an 8.  And many more after that (who knows if marketing will actually call them those names though).  I can say this with some certainty because, 1) We’ve been very successful and 2) We have so many features on our plates that we’re not going to run out of things to do anytime in the recognizable future.

When we start a project, the first thing we have to decide is what features we’re going to do.  Like I said, this usually of the form “of these 1000 great features, which 100 can we reasonably get done in time?”  Having so many users, each with their own passionate opinions on what’s important, many of them conflicting, makes this a tough choice.  Even if we only had a million users (we’ve got many more than that), if we chose something that 99% of them wanted instead of something that 1% wanted, we’d still annoy 10,000 people.  Remember this when you say, “All of my friends want this too.”  Even if you personally know ten thousand people and they all agree with you, that’s still a tiny percentage of the user base.

But it’s even harder than that.  Sometimes it’s not just “the people who didn’t get this feature will be disappointed.”  Some features are great for most of our users, but make things appreciably worse for some of them.  We’ve had some features that were absolutely critical for half our users, beneficial for forty percent of them, unimportant but not bad for five percent, a net negative for four percent, and absolutely unacceptable for one percent.  On percentages, that would seem like an easy choice, until you have to sit in a room and decide to literally make tens of thousands of users furious at you.

Even the “easy” decisions aren’t.  Mobile Operators wield an enormous amount of power in the phone space.  All they have to say is, “We won’t sell your phones unless you do this,” and the decision is made for us.  But, some of those required changes have made end users angry at us.  Even when we know the change is going to be unpopular, if we tell the Mobile Operator that and they say “tough, do it anyway,” we have to do it.  If we can’t sell our product, we don’t have a product. 

But then it’s easy, right?

Okay, so our friend the feature made it through the gauntlet and has been approved.  Now we just need to write the code and release it, right?  Unfortunately, no, it’s not easy.  Even when the code itself is relatively easy to write, there are a lot of things that make it complicated. 

First, we ship Windows Mobile in around 25 languages.  So, if the feature displays any words, those words need to be translated a few dozen times.  Worse, words in some languages are much longer than words in others.  This means that what fits on the screen in one language might not fit in another.  So it’s not just translating sentences.  It’s also laying the UI out over and over again. 

Both the code and the languages are also made complicated by the wide range of devices we have.  It generally needs to work on both a PocketPC with a touch screen and a Smartphone that doesn’t have one.  It needs to work if you have a lot of buttons or just a DPAD.  It needs to work at 640x480, 480x640, 320x240, 240x320, 480x480, 240x240, and 176x220.  And remember that you need to multiply each of those screen sizes by the number of languages.

Then there’s the security review.  In the good old days, users tried to use their devices in the ways they were intended to be used.  If there was a place to enter the number of dogs you own, we expected you to enter 0 or maybe a number between 1 and 10.  To be safe, we might have covered up to 1000 knowing that almost no one owns 1000 dogs.  Little did we know that some aspiring spammer would find a way to say that he has 4294967295 dogs, and that, due to a subtle bit of programming, that would cause the software to misbehave in a way that enabled him to steal money.  We no longer get to write software that just does what the users need it to do.  We now need to write software that does what users need and is hardened against known and unknown attacks by malicious people who will spend years looking for new ways to beat it.  An attack similar to the four billion dogs one once shut down an airport.  No matter how much users want the feature, security isn’t something we can ignore.

Well, at least you don’t have to test it…

A frequent dig is, “This code was rushed to market and no one bothered to test it.”  Our intrepid friend the feature will tell you that this isn’t true.  We spend a lot more time testing our code than we do writing it.  (The number of features we can do in a release is almost always decided by how many we can effectively test, not by how many we can code.)   A feature will usually have a group of testers specifically assigned to it.  Then, after a week or so of dedicated testing, we’ll do “integration testing” to see how the feature impacts other parts of the system.
 
After focused testing, the feature is put into a nightly build so that everyone on the team can “dogfood” it.  We have a concept here we call “eating our own dogfood.”  Basically, this means that, throughout the development of the product, all of us are using it on our own phones.   We generally will not ship a product that didn’t have significant dogfood exposure (minimum hundreds of users for multiple months).  When we’ve finished coding all the new features, we’ll spend a couple of months doing both focused testing and dogfood.  We also hold ourselves to doing testing and dogfood of bug fixes.  In general, the final release comes a week after the last bug was fixed, and generally three to four months after the final feature was added.

But then it’s done, right?

No.  Our product is not a phone.  It’s an OS and applications that we ship to our OEM partners.  It’s the OEM’s product, built upon ours, that’s a phone.  The OEMs design and build hardware to use our software, and then they write a ton of their own software for the device.   Often, less than half of the code on Windows Mobile device was written by Microsoft.  We give OEMs early drops of our part so that they can work somewhat in parallel with us, but there will always be a lag between when we finish and when they are able to ship their devices.

When the OEM is finished, they then need to take the device to Mobile Operators for acceptance testing.  They need to do this for every release of every device, need to do it individually for each MO, and need to wait for an available spot in each MO’s busy testing schedule.  Once acceptance testing starts, it tends to take multiple weeks to complete.

The total amount of time that passes between when we release our product and when the finished phone becomes available from the MO varies with a lot of factors.  If it’s a small update to an existing piece of hardware on a phone that the MO is already selling, things go much more quickly than if it’s a major release on a new piece of hardware the MO has never seen before.  I’ve seen this take as little as a month an as much as six. 

And then it’s done

This is the point in the “I’m Just A Bill” cartoon where the senator runs out and exclaims, “He signed ya, Bill.  You’re a law!”  Once the Mobile Operator accepts the phone, it shows up in stores a little while later.  Sometimes there’s a bit of delay for a marketing campaign or to get a bunch of units manufactured, but it happens pretty quickly after that.   

In a nutshell (okay, a really long and verbose nutshell) that’s how ideas become features here in Windows Mobile. 

Mike Calligaro

Comments

• Anonymous
  September 11, 2006
  Last week, we asked for your suggestions on how to improve the Xbox 360 dashboard. As a result, I was

• Anonymous
  September 11, 2006
  Great article!

• Anonymous
  September 11, 2006
  A related question is "Why isn't this (new feature | fixed bug) that I just mentioned in the next version of Windows Mobile?"
  
  If you lay out the timeline that Mike describes above, you can see that there's a long lag time (months and months) between when we finish development on a revision of the software and when it gets through OEMs and operators to the customer.
  
  So sometimes the answer is "Because the next version of Windows Mobile had already been finished at the time you asked".
  
  And other times the answer is "We've already (fixed|added) it in the version that we're working on, but can't yet discuss because it's not publically announced."

• Anonymous
  September 11, 2006
  Fantastic article Mike, now if only there was some way of forcing users to read and understand the many issues forced upon software developers, the world would be a happier and more understanding place :)

• Anonymous
  September 11, 2006
  As someone who deals with software project management and web development on a daily basis I'm archiving this one to pull out next time a client insists we should break the product freeze in favor of feature creep ;)
  
  Thank you!
  
  Joe-
  Chief Gaming Officer
  www.gamehelper.com

• Anonymous
  September 11, 2006
  this article should be shipped with every piece of software microsoft or any company makes. great explanation. i understood this whole article but i understand programming and testing, but i think even those who do not should still get it. its just basic logic people overlook most of the time.

• Anonymous
  September 11, 2006
  Great Article!,

• Anonymous
  September 11, 2006
  Awesome article. Let me know when you have the song and cartoon to go along with it finalized.

• Anonymous
  September 11, 2006
  Very, very well written article.

• Anonymous
  September 12, 2006
  The article was very intresting to understand the policy of Windows Mobile OS development. You have achieved outstanding quality of Windows Mobile software so far. But the trade off is 10000 of mad users due to very poor features.

• Anonymous
  September 12, 2006
  Awaiting an obvious "why not just open source Windows Mobile, it's that easy and you'll make thousands of geeks happy" type of comment.

• Anonymous
  September 12, 2006
  I want a web browser for the xbox 360. Its an entertainment platform so complete it as the complete entertainment platform with a browser.

• Anonymous
  September 12, 2006
  I would like Achievements and Icons for old XBOX games.... So like if a person plays Halo 2 or Links 2004 or a Backward Compatibility Game it will show on on your XBOX.COM.. also I would like to keep www.xsnsports.com open...

• Anonymous
  September 12, 2006
  The comment has been removed

• Anonymous
  September 12, 2006
  Hello, it can be fun to have MSN integreted in the xbox dashbord. Also it can be fun to be able to listen a video with the xbox guide bouton.

• Anonymous
  September 12, 2006
  I public bug tracker would be nice though. Then you would atleast know that a given issue is just waiting to get released to OEM's.

• Anonymous
  September 12, 2006
  How about that multiplication program :-)

• Anonymous
  September 12, 2006
  In the section that displays Messages, Friends, and Players, it would be great if there was a fourth subsection showing the status of your Windows Live Messenger contacts. Or, just as a standalone option on the main dash.
  
  I know that this would take a lot of work, but that one thing would probably be the best dash update conceivable!

• Anonymous
  September 12, 2006
  PingBack from http://blog.funknstyle.com/?p=544

• Anonymous
  September 13, 2006
  A good read.  I always knew that things like this were complicated, but to have it spelled out is helpful.
  
  Now I'm just wondering why people are posting suggestions for the 360 UI here

• Anonymous
  September 13, 2006
  I'm glad you folks found this useful.  
  
  For the people suggesting Xbox 360 features, this blog is for Windows Mobile (Smartphone and PocketPCs), not Xbox.  Major Nelson linked over to here because the general design process is similar for Xbox and Windows Mobile.  (It's probably similar for all major software development houses.)  It's unlikely that many Xbox people are reading these comments though.  You're better off making your suggestions on a Xbox-focused blog like Major Nelson's.
  
  Mike

• Anonymous
  September 13, 2006
  excellent article. As a long term user of mobile devices I promise I will never complain again about missing features/unwanted features again. All is now clear... thank you and keep up the hard work

• Anonymous
  September 13, 2006
  excellent article. As a long term user of mobile devices I promise I will never complain again about missing features/unwanted features again. All is now clear... thank you and keep up the hard work

• Anonymous
  September 13, 2006
  So how do we get the veto power out of the MO hands?  Sure, they control their network, but contrary to their popular belief they don't control the device at a feature level.  I'm of the belief that if the feature doesnt do anything harmful to the MO network, it should be allowed in.  I think there becomes a time where users will drop a MO if they DON'T offer a Windows Mobile device.  Due to the popularity of Blackberry I dont think too many MOs wield as much power over RIM.

• Anonymous
  September 13, 2006
  That's one way to manage it. The other way is to be brave and do things the way you think it should be done and let the users decide if they follow you. The problem with becoming all responsible too early is that you get users used to bad design. Then, bad design becomes "ok" design that you can't change because you're too afraid to.
  

• Anonymous
  September 13, 2006
  On the windows mobile team's blog.
  I hope that whoever is quoted in this eweek article saying that public...

• Anonymous
  September 13, 2006
  PingBack from http://www.boschmans.net/2006/09/14/how-windows-mobile-5-gets-developed/

• Anonymous
  September 14, 2006
  I agree 100% with what you wrote.
  Not counting the old bugs that may become "features" for some users.  In a previous life at yet another software company, we had to implement a compatibility mode preserving some of the most infamous bugs because customers migrating from old version to new one were not expecting bad results to become correct, they preferred their bad results to stay so !

• Anonymous
  September 14, 2006
  PingBack from http://www.standingmobile.com/i-am-really-just-a-feature/

• Anonymous
  September 16, 2006
  I'm a feature to be
  Yes, a feature to be
  and I'm hoping they will implement me
  
  There's a lot of LIVE gamers
  who have notice something lacking
  I want to get the backing,
  so that we can finally appease them
  
  But there is limits to our abilities
  atleast I hope and pray there aren't
  'cause those million geeks may go too far...

• Anonymous
  September 18, 2006
  I have finally got my outlook unread messages down to zero. There are 1229 Messages in my deleted Items...

• Anonymous
  September 18, 2006
  Software / Hardware Engadget gives us a few of HTC’s Q4 lineup . Here’s a link to their European press

• Anonymous
  October 05, 2006
  I’ve done blog entries on compaction threads, memory consumption, difficulties in doing upgrades, voice

• Anonymous
  January 20, 2007
  PingBack from http://myhalonews.com/news/how-an-idea-becomes-a-feature/

• Anonymous
  April 18, 2007
  PingBack from http://www.mubweb.com/blog/?p=61

• Anonymous
  August 23, 2007
  There are two kinds of APIs you don’t want to make friends with in this world – undocumented and deprecated

• Anonymous
  August 23, 2007
  There are two kinds of APIs you don’t want to make friends with in this world – undocumented and deprecated

• Anonymous
  August 23, 2007
  PingBack from http://msdnrss.thecoderblogs.com/2007/08/23/undocumented-and-deprecated-apis-you-dont-want-on-your-friends-list/

• Anonymous
  October 24, 2007
  <<The only reason I could get away with such a pain free development cycle is that my target audience was extremely small.>> Oh come on! What do you expect - he's only 8!

• Anonymous
  October 24, 2007
  (-: Mike