by Michael S. Kaplan, published on 2006/10/15 18:42 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/10/15/829978.aspx
There are times that no matter what we do with a particular behavior at Microsoft, there will be somebody, somewhere who will find the behavior to be incredibly non-intuitive and they will consider it to be a bug.
I mean it drives lots of .NET developers crazy that there is no SHORT TIME FORMAT support in Regional and Language Options, as I have mentioned in Customizing the SHORT time format? and We do seem to be short on time.... Despite the fact that SHORT TIME as an independent entity has never existed in Windows and is only something you can get to indirectly via GetTimeFormat and its various flags (as I mentioned before).
The problem: Windows and .NET are simply not integrated enough in this case, according to some developers.
Fast forward to that case that drove some other .NET developers crazy (it could have been the same ones, though I am hoping it is not!), the problem I explained in .NET is too busy being consistent with Windows to be consistent with itself.... Developers who ran into the problem were finding a situation where the user preferences were being followed to be entirely un-intuitive and they wanted the .NET Framework to just ignore Windows so it can take care of its own settings better.
The problem: Windows and .NET are integrated too much in this case, according to some developers.
Of course, it boils down to consistency and compatibility, and both of these qualities are very important to customers.
The only problem is the answer to two simple questions:
Consistent with what?
Compatible with what?
If .NET is consistent with itself then it is more likely to be compatible with itself as it is run on different platforms with different settings. But then there are many cases that this will break user expectations.
If .NET is consistent with Windows then managed and unmanaged applications have as better chance of being compatible with each other, and since users can easily be running both on their copy of Windows, that compatibility will be just what they expect. Well, until they install the application on a different versions of Windows and/or a copy of Windows with different settings.
In the end there is no way to completely win this battle unless there is 100% feature parity across all versions and across both unmanaged/managed code, which would also mean no adding new features unless they are also added to previous versions.
And of course then the battle with people who do not want behavior changes in service packs, the people who do not want new features in service packs, and the people who want neither, will not be very happy. and rightfully so.
It is easy to say we should have just never supported the SHORT TIME FORMAT; we should have dumped it before it ever shipped in version 1.0 of the .NET Framework. Just like we did with the MEDIUM DATE FORMAT, another COM feature that we are well to be rid of. If we had just added configuration settings to long time formatting to match the analogous GetTimeFormat features implicit in its customization flags. But even if that would have gotten us around the problem, it is a bit too late to do anything like that now....
That we have decided for the current releases to neither
nor
could be fairly (and unfairly!) attributed to many different factors, though the reign of user-created confusion is not going to go away until one or the other is done (either in Vienna or in Orcas (well, post-Orcas, to avoid red-bit/green-bit confusion). I am not currently aware of any plans to do either or both, at this moment.
Though perhaps in this world where no matter what we do we will be accused of making a mistake in regards to intuitive behavior, consistency, or compatibility....
This post brought to you by ណ (U+178e, a.k.a. KHMER LETTER NNO)
Igor on 16 Oct 2006 5:09 PM:
Michael said:
"And of course then the battle with people who do not want behavior changes in service packs, the people who do not want new features in service packs, and the people who want neither, will not be very happy. and rightfully so."
Well there lies the problem, in bundling.
Do NOT bundle ADDING or REMOVING FEATURES with BUG fixes.
Michael S. Kaplan on 16 Oct 2006 6:12 PM:
Well, that is what I was saying -- that this is an argument against updating all past versions as way to level the playing field?
Glad we agree! :-)
referenced by