I've been working on the CLR team now for slightly over 2 years (FYI: been at MSFT for 5.5). I've learned a great deal in that time about managed code (and native code too), new programming concepts, managing large teams (there are about 150 us now) and some other odds and sundries. I've also had access to early hardware from our friends at AMD and Intel. None of that surprises me now, nor would it have suprised me back in late 2003 (when I started). One concept that I have picked up that I didn't expect was around correctness. Maybe I just missed class the day they taught "correctness", but it was new to me, at least to the degree it is taken seriously on this team.

I took a look @ Wikipedia to see what it thought about correctness. The definition there flirts with what I think of correctness, but it isn't quite it. The closest bit on Wikipedia is this bit:

"In theoretical computer science, correctness of an algorithm is asserted when it is said that the algorithm is correct with respect to a specification. Functional correctness refers to the input-output behaviour of the algorithm (i.e., for each input it produces the correct output)."

If I can construe those two sentences into something slightly more precise, w/rt what I'm thinking ... An algorithm can be considered correct if it produces a result that is predictable (including predictably random) and satisfies the requirements of all of its users (including potential users) under all required scenarios (including potential scenarios).

Another way of thinking of this is not going half-way with an implementation for some method. You need to solve the entire problem from all angles. You need to consider the turkish i and the multiple sort orders of the thai character set (sorry:pdf link). You also have to consider proper locking semantics, avoiding race conditions and dead locks when called/exercised from multiple threads. One can all consider "not guaranteed to be thread safe" as another form of correctness, since the contract is specified up front. One could argue that stance though. You also have to ensure that you clearly specify the expected behaviour of operations, particularly when casting between data types. You also have to determine what should be done when you run out of stack, memory or other resources. What happens when the machine loses power in the middle of an operation. Are you in a consistent state when the machine comes back to life?

So, back to the CLR team ... I find that the concept of correctness comes up a lot in our design sessions and general conversations. The world, in a very real way, is building massive amounts of code across an infinite number of possibilies and scenarios on top of the runtime. It is impossible for each (or any) of us on the CLR team to understand all of those scenarios, let alone take them all into consideration at each step during our development. Instead, we try to learn about as many weird and wacky ones as possible to help us, but correctness is really the thing that guides us each day. It may well turn out that our platform is not feature-rich enough in some niche areas. That's fine, and will always be the case to some degree. Developers still need to write code ;) What isn't acceptable is that our platform operates incorrectly (lack of correctness) in some corner case (or worse yet, general case) scenario. Provided that we think hard and build correctness into every layer of our platform and line of code, we can be certain that the runtime will perform properly and correctly in those infinite number of possibilities and scenarios.

That's one of the reasons why I love working on this team ... not as much because I want to ensure that the runtime is correct in all cases, but because I find it incredibly interesting learning what the correct behaviour is in all those cases. Sometimes it is obvious, but other times it requires a lot of thought to understand why something is correct if done that way. And even more interesting yet is when you're the guy (or gal) who needs to determine what the correct behaviour is, and defend it to your peers. That sort of analysis and hard thinking definitely requires those extra brain cells and cycles that are not neccessarily used every day. And then you sleep really well the next night ;