Welcome to MSDN Blogs Sign in | Join | Help

Kathy Kam

Reflection on the CLR and .NET
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"?

Posted: Tuesday, April 18, 2006 8:00 AM by KathyKam
Filed under:

Comments

Quentin Pouplard said:

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
# April 18, 2006 12:41 PM

KathyKam said:

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.


# April 18, 2006 4:01 PM

TAG said:

> 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.  
# April 18, 2006 4:49 PM

KathyKam said:

What about Rotor 2.0 that just shipped last month?
# April 18, 2006 9:01 PM

TAG said:

> 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.

# April 18, 2006 11:17 PM

KathyKam said:

This opens the whole Open source debate that I just prefer not to go into. :P
# April 19, 2006 7:54 PM

junfeng said:

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.
# April 27, 2006 3:54 AM

KathyKam said:

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.
# April 27, 2006 8:41 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

  
Enter Code Here: Required

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker