-- techie blog posting alert --
This writes about a lot of what I like to explain to others about Microsoft product stability. I honestly believe that MS has got some of the most convenient software on the market. However, with any product that's constantly trying to add "innovation", or more honestly, just nifty features, it's hard to do that without building off of what you've got. Then it becomes a race to decide what's more important the new features (that may probably sell the new product more), or refactoring to increase stability. Then again, if you refactor, how many *new* undocumented bugs are you now introducing? Tons, most likely.
So you go the way of testing -- try to pound on the software, and fix it where it's broken, but still overall follow the mantra "if it's not broken, don't fix it". This means that eventually poor design decisions get left in code, for ages to come. I'm not sure if this is really avoidable
I remember very well in Comp410 when I was working on my largest collaborative group program at that time, and still being hesitant to refactor code in risk of breaking interop with others' code, in such a short timecrunch. Especially changes in the interfaces that the other code links against -- you then know they have to change their code, and getting them to change it the right way can be frustrating -- and you know you don't have time to change it all for them.
Probably for that class, one of the most realistic things was having a realistic hard and fast deadline. After that was imposed, it was funny how conservative people projected in their estimation of how much progress could be made in a given time interval.
Well, "c'est la vie".