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"?