Whoa - cruft

Well, if this piece from Joel is accurate about this story, it explains a lot of the problems in Windows all by itself:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

If they actually do this kind of thing, it's very, very bad. Why? These kinds of awful hacks tend to add up, and the crossing of 2 or 3 (or 4 or 5) of them end up generating interesting side effects. I've walked myself into this kind of corner in various tools of my own - I did this with the Blog Posting tool awhile back (and I'm still trying to find my way out of the nasty hole that I ended up digging). These sorts of hacks seem to make sense in the short term - but they end up making for a really hard to test system - one in which a combination of hacks makes for completely unpredictable (and, from the end users perspective, essentially random) behavior. If they did this for Sim City, you have to figure that they did it elsewhere. This is just bad, and the people at MS who thought this was appropriate should be removed. This is the sort of thing that rewards bad practices - heck, it positively encourages bad practice.