Feature Requests… why don’t we just do them all?


Today, I learned an intersting (and very important) lesson about building a framework. I was in a meeting where another team wants the BCL’s support to add some APIs to WinFX. The APIs they want to add are valuable. It gives power to .NET developers to do something new, it opens new doors. It seems brain-dead obvious that they should be allowed to add it. As a matter of fact, sometimes, when I look over the 1100+ feature request on the BCL team, it feels brain-dead obvious that we should do every single one of them. Our users usually have great feedback, and many of them does make it into our feature request database. However, we do not do all of them. Our users may ask… why? why not?


Well, the main reason is because we have limited resources. Every feature, change, bug fix takes time, energy and effort. This is relevant in all products Microsoft ships. Back in my Outlook days, I faced the same problem. (Should we fix a bug that causes meeting to drop off on your calendar or a bug that cause reminders not to fire?) Every group in Microsoft take great care to make sure that we are using our resources most efficiently. With limited resources, we try our best to deliver the most value to our customer. This means delivering the most important, the most painful to live without feature first. That’s why the question Krzysztof asked in the BCLTeam Weblog was very interesting. He didn’t ask “What do you want in the BCL?”, he asked “how would you spend the limited resource (fake BCL brownie points) you have?”


Today, I learned a second reason. Even if we have unlimited resources, armies of testers and developers to do these feature requests (Like this group that is willing to pony up the PMing, Deving, and Testing of their favourite feature), why in the world would the BCL/CLR even consider not approving it? 


Sometimes, less is more. This is particularly true when it comes to anything that interact with users. It doesn’t matter if it is the framework or the UI. 


A framework with multiple ways of representing a string (ahem.. anyone remember those bstr, char[], wchar[], etc… ) causes confusion. When I was a developer in Outlook, every file has its own version of string. Instead of opening new doors, allowing new ways of coding, this actually slows developer productivity. Who wants to use a framework that you can’t tell what to use and why? A bloated framework is unmanageable. Similarly, a overly crowded UI is unmanageable. That’s why Office has decided to design the ribbon. I am not going to go into UI design in this blog. I leave that to my friend Jensen, UEX PM lead (also an ex-Outlook PM), who wrote “Why of the New UI” series to explain the problems of the overcrowded UI that plagued Office users.


What do you think? Agree? Disagree? When you design your software, have you ever decided not to put something in it because “Less is More”?

Comments (8)

  1. Quentin Pouplard says:

    I agree… and disagree, basically you explain that you don’t want bloated framework, I agree, and that adding feature can make it bloated, I also agree… but on the other side, technologies (like .NET) allow developer to add feature near the other, with limited interaction.

    .NET framework 2.0 has new feature, for some of them, there is no reason (other than resource) not to be in 1.0 (or 1.1) (I think about ssl support, generics, etc…)

    Also language allow feature to look like existing, even if technically they’re in a different module/assembly/part of stuff, I think about extension method for instance. Maybe that’s were we should look when thinking about adding new feature (and the good news is that it seems that ms is doing it! no need to make feature request for a new method thatdoesexactlywhatIwantbutnootherlivingcreaturewant() on string).

    I totally agree with less is more, *from the user point of view*, sometimes to make the user believe it get less (complicated, bloated UI/API) you’ll have to do a lot more, and I think that’s were it becomes really difficult (it seems that has been the choice for ribbon: drop some legacy code, rewrite it, to make more while making looking like "less").

    And as a final touch, in entreprise real world, where business pays for IT, sometimes less is … just less: adding a power user feature that will be so powerful that nobody will realize it’s actually a feature is sometimes difficult: nobody want to pay for it. In lot of companies we still have to speak in term of buttons or screen to describe application. That’s also true for non-feature like security: unless we got critical exploited flaw, it’s sometimes hard to convince people to pay for a code-review. Anyway, enough of blabla, I’ll post some feature request :p

  2. KathyKam says:

    I agree with your comments there. The people who spend the money to purchase a product in an enterprise is different from the people who generally uses the product. It’s the IT manager vs the IT Programmers.

    It is sometimes very difficult to convince people who spend the money that less is more, to them… less is just less. They ask themselves… "Why would I pay for something that and get less than what I already have?" Again, drawing from my experiences in Outlook, there are areas that are not highly used and quite outdated, and it cost Microsoft heaps to keep that feature around (Anyone here uses Journal?), but we can’t get rid of it because it will seem like the next release is less.

    Here in the CLR, we are faced with the same problems. There are APIs we want to obsolete, we want to give our users something better, but we can’t. As long as we have any paying customer is depending on it, it is very difficult to tell them that, their software might break after upgrading.

    We need to strike the right balance here.. producing a great platform, and still add enough "new value" to it.

  3. Garry Trinder says:

    > we have limited resources

    This is problem with MS.

    We ask for features becouse we need them to do our real-world job.

    I rate all requests that only Microsoft can address very very high at ProductFeedback.

    If you would like to help us (your users) – add us as your resources ! Open sources to products like BCL / .NET runtime or WinForms.

    WinForms idea was already discussed –

    http://www.shawnburke.com/default.aspx?document=185&userinterface=9

    but results are unknown.  

  4. KathyKam says:

    What about Rotor 2.0 that just shipped last month?

  5. Garry Trinder says:

    > What about Rotor 2.0 ?

    License !

    http://msdn.microsoft.com/MSDN-FILES/027/002/097/ShSourceCLILicense.htm

    > You may use this Software for any non-commercial purpose, subject to the restrictions in this license.

  6. KathyKam says:

    This opens the whole Open source debate that I just prefer not to go into. 😛

  7. Personally I think BCL lacks of many useful features. You can say that you have limited resource. But the direct result is that many people have to re-invent the wheel many times.

    Since BCL is mostly about utility code. maybe it makes sense to have BCL team sponsors a JSP like process, where interesting parties present their feature requests and their implmentation, and the committee decides what go into the next version. You don’t even need to make the process public. I am very sure there are significant common interest in BCL’s internal customers and external customers.

    Less is more means do more with less. A missing feature is a missing feature. How do I do more when the feature does not exist? Jensen’s blog isn’t about not adding new features. It is about how to streamline the UI interface so that more features are easily exposed. It is apple and orange comparing that with BCL’s misisng features.

  8. KathyKam says:

    Interesting feedback Junfeng. The BCL gets an amazing number of feature request. Someone somewhere will always feel that there is one VERY important feature BCL is not providing. I doubt BCL will run out of features anytime soon and we are working towards providing as much useful features as our resources allow. 🙂 I find your committee style of giving us feature implementation interesting. However, I am not sure how many components BCL will take even if we have such a process. For a feature to go into the BCL, we take great care to make sure we are not bias towards any specific language, scenarios or group. BCL features are universal… it’s the base class for everyone afterall. We go through review after review, each member is carefully selected and named. It will probably take just as much resources to adopt a feature another team gives us as writing our own. Much of our work is in the design. That’s why the .NET Design Guidelines came out of our team!

    Now… regarding my comment about “Less is more”. Yes, sometimes a missing feature is a missing feature, but that’s not my point. Notice how I didn’t say “Always, less is more”. I said “Sometimes, less is more”.

    In a framework where there are multiple ways of doing the same thing, like… Remainder and Mod.. What’s the difference? Why do we have two? These are the scenarios where I honestly believe one API is sufficient.
    Having multiple APIs that does something SLIGHTLY different (or even NO difference), doesn’t add enough value for the framework as a whole.