Mistakes were made. Mistakes such as having Windows NT put Notepad in a different location from Windows 3.1. (Though I’m sure they had their reasons.) Mistakes such as having a TCS_VERTICAL when there is already a CCS_VERT style. Mistakes such as having listview state images be one-biased, whereas treeview state images are zero-biased. But what’s done is done. The mistakes are out there. You can’t go back and fix them—at least not until time travel has been perfected—or you’ll break code that was relying on the mistakes. (And believe me, there’s a lot of code that relies on mistakes.) You’ll just have to do the best you can with the situation as it is. Often, when I discuss a compatibility problem, people will respond with “That’s your own damn fault. If you had done XYZ, then you wouldn’t have gotten into this mess.” Maybe that’s true, maybe it isn’t, but that doesn’t make any progress towards solving the problem and therefore isn’t very constructive. I sure hope these people never become lifeguards. “Help me, I’m drowning!” “Are you wearing a life preserver?” “No.” “Well, if you had worn a life preserver, then you wouldn’t be drowning. It’s your own damn fault.”

When faced with a problem, you first need to understand the problem, then you set about exploring solutions to the problem. Looking for someone to blame doesn’t solve the problem. I’m not saying that one should never assign blame, just that doing so doesn’t actually solve anybody’s problem. (If you want to blame somebody, do it at the bug post-mortem. Then you can study the conditions that led to the mistake, assign blame, if you’re looking for a scapegoat, and take steps to prevent a future mistake of the same sort from occurring. As a lifeguard, you first rescue the drowning person, and then you lecture them for not wearing a life preserver.)