by Michael S. Kaplan, published on 2010/04/09 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/04/09/9992866.aspx
I am told I have something of a reputation for being a huge stickler about backcompat and proper usage, such that on at least three occasions I have been described to someone who was to make contact with me in such a way that they assumed I was some crotchety 60 year old grouch who can't stand change.
Thankfully I was able (in the long run) to convince all three that the description was [at least partially] inaccurate. :-)
But I was thinking about this the other day when a question came up.
Someone who was wondering about what kinds of tests existed to catch when people were doing international support incorrectly.
When pressed for details on what kinds of tests/checks he had in mind, he said something that struck me so much that I moved this blog you are reading from Sunday to today and gutted the original introduction entirely and wrote the one you are in the middle of reading!
You might be curious what could it be that was so memorable in his reply.
If you aren't then I have to wonder why you are still reading here, of course!
It was pretty simple:
Since I haven’t look at the code yet it is hard to come up with examples. The only one that comes to my mind is the use of en-US locale to get invariant sorting behavior instead of using the invariant locale.
I was shocked.
That is not something I would ever ask someone to change, for a very simple reason:
"Invariant sorting behavior" and "en-US sorting behavior" are identical!
Now when you combine this with the known fact of the second tester's axiom, the thing you risk if you simply choose to replace all those instances is regressions when the change is done improperly. And the axiom is clear that such things are not only possible but can often be expected!
For those who figure it is an easy change, I highly recommend getting to
a tester (in my experience any of the three of those options can help here!); said tester will quickly help you appreciate the mistake in judgment there. :-)
Now we can perhaps re-frame the question a bit into something more actionable, and someone who owns that code can determine if the code that is present is wrong.
Perhaps the default user locale would provide the correct intended behavior.
Or an "ordinal" (binary) comparison might be the riught thing here.
And I would never tell someone who had such a flaw in their code's design to ignore it if they found it.
But if you show me a developer who would clean up the cases that aren't problems then I'll point out you've shown me a developer who introduces a lot of regressions in the code base. :-)
Deskin Miller [MSFT] on 9 Apr 2010 10:11 AM:
I rather disagree with the premise you distill here, particularly the way you phrase it in the last line. Testing one's code is a great way to stand behind any assertion that it is not broken; thus if one refactors code which is covered by unit tests, one may have high confidence that the change does not introduce regressions. Development processes like TDD focus on leveraging unit tests for this and many other benefits.
Certainly 'cleaning up the cases that aren't problems' may introduce regressions, but it need not.
Michael S. Kaplan on 9 Apr 2010 12:53 PM:
Well, one could log the next 100 such changes along the lines of the one mentioned here that are done and do a longitudinal study -- in looking at specific groups in that way I have found my conclusions to be correct. :-)
Whether it requires one to be likely to have 100 such changes to review may be related!
I have yet work on any team that used TDD so I cannot comment authoritatively on whether TDD can help mitigate Axiom #2.....
Mihai on 9 Apr 2010 6:10 PM:
> "Invariant sorting behavior" and "en-US sorting behavior" are identical!
I think "they just happen to be identical today."
Ok, it is not a random "happening," it is caused by the fact that for a long time there was no invariant locale, so people were advised to use en-US. So when a real invariant locale was introduced, it was only natural to make it identical to en-US, so that things don't break.
But locales change. In (in theory) nothing prevent en-US from changing (it happened with other locales before). Unlikely? Yes. Impossible? Probably not.
Plus, it helps clarifying the intent. Same as using BYTE instead of unsigned char, or NULL instead of 0.
So, when you mean invariant, use invariant, not en-US :-)
Michael S. Kaplan on 9 Apr 2010 6:38 PM:
These two will always be the same.
I described its origin and purpose here.