Why didn't Microsoft fix this horrible bug?

No excuses

I do want to be clear about something: this isn't about making excuses for Microsoft. They do screw up and miss important things from time to time. More often than not, it's a case of not clearly understanding the priorities of their users, but even that is no excuse: sometimes, they get it wrong.

This is more about explaining and trying to understand the process and the incredible complexity of the problem, and with that, gain a little bit of an understanding about why a "bug" might not get resolved in a timely fashion.

To me, part of the "no excuses for Microsoft" position of what follows is that it applies to any and all large systems vendors. Even though I'll use "Microsoft" in the discussion below - mostly because that's where I have experience - the discussion applies equally well if you replace Microsoft with Apple, Mozilla, Google, Intuit, or any of a hundred other software manufacturers.

And not to minimize your experience

I also don't want to minimize or gloss over the impact of whatever it is that you're experiencing. The bug could indeed have a significant impact on the way that you use your computer every day.

I am taking your experience seriously - as does Microsoft, believe it or not - but I also want to be pragmatic.

Because your experience has such an impact on you, I think that it's important to understand the realistic chances of getting it addressed, as well as making sure that the correct culprit is being blamed.

Sometimes it's just not a bug

I've been putting the word "bug" in quotes above because sometimes, it truly isn't a bug at all. Sometimes, it's intended behavior.

Just because you don't like something doesn't mean it's a bug. It may annoy the heck out of you, but that doesn't mean that it's wrong or accidental.

Microsoft really does do research to determine the best way for things to work - lots of research, typically referred to as usability studies. They update and refine their products based in large part on the feedback that they get from real people using the proposed changes long before those ever see the light of day - and indeed, based on that feedback, many such changes never make it into the product.

But, there's no pleasing everyone.

If 900 people really like a proposed user interface and 100 don't, you can bet that Microsoft will normally choose that which pleases the most. (Actually, they'll try to get it to be more like 990/10 first, but that's somewhat beside the point here.) If you're one of the 100 ... well, when it comes to that feature, you're out of luck.

It's not a bug, it's a decision that appeals to the majority of users - a majority of which you, unfortunately, are not a part.

Sometimes it's just not that important

There are bugs in Windows that I'm certain are well over a decade old and will never be fixed.

Why?

Because the number of people impacted by the bug or the severity of the bug's impact is so small as to not be important enough to fix when compared with making other progress on the product.

So, let's say that you've actually found 1,000 people who have experienced what you believe is the Most Important Bug Ever.

The number of Windows installations was expected to exceed 1 billion machines in 2008.

You have 0.0001% of Windows users experiencing your Most Important Bug Ever.

Now even the fact that 1000 is actually a teeny, tiny fraction of Windows users isn't enough to get the bug ignored - it's just one factor.

The phrase "data loss" is another.

One of the classifications assigned to problem reports is the concept of "data loss" - meaning "does this particular bug cause the user to lose data?" That could be as simple as a crash that causes you to lose what you were working on right now, or some other kind of failure that unexpectedly wipes out all or part of the data stored on your hard disk.

Data loss matters.

If a part of the screen isn't re-drawn as it should be or a mouse pointer is lost or an information window closes unexpectedly, those are all significantly less serious than something which causes a user to lose data.

So even if there are thousands of people experiencing the same problem, that might be tiny compared to all of the users that are not. If the problem is mostly non-destructive, you can see that it might not get prioritized as highly as other issues - including even future product and new feature development.

Sometimes it's not Microsoft's bug

One of Windows' most compelling features is its ability to be extended by third-party hardware vendors. Today's version of Windows is able to work with hardware that hasn't even been dreamed of yet simply because when that hardware finally does come into existence, the manufacturer is able to write software (aka drivers) that integrate with Windows to bring support for that new device.

The key phrase there? "The manufacturer is able to write software ... that integrates with Windows".

Neither you nor I really care about where the line is, but Microsoft didn't write, and isn't necessarily responsible for every bit of software used by Windows to run your machine.

What that means is that some of the bugs (unfortunately, it's occasionally "many" of the bugs) that users perceive of as being in Windows aren't in Windows at all. Those bugs are in the software that's been added to Windows by other vendors. (And even there it can be tricky to understand who's responsible because hardware drivers can cause symptoms in seemingly unrelated areas - for example, display driver problems can often affect the mouse's functionality.)

Microsoft can absolutely pass along reports of issues with third-party software, but they don't control how, when or even if those bugs get resolved. They, like you, are at the mercy of those third party software authors.

This isn't limited to drivers, by the way. There are third-party applications and addons that are often perceived as part of Windows, even though they are not. When they fail, they often report as failure in a Windows component when in fact, the fault truly does lie elsewhere.

Fixing bugs is risky, and expensive

Unfortunately, fixing a bug - even a simple one - is neither simple or cheap.

Because of the incredible, unimaginable complexity of the systems that we take for granted these days, the ramifications of even the smallest bug fix are often difficult to completely predict. It's not at all uncommon for a bug fix here to break something else "over there".

Hence, a good software vendor tests even the smallest fix thoroughly.

What that means in Microsoft's case is that all of Windows needs to be run through a complete testing cycle to make sure that nothing was broken by the fix.

Imagine what it means to test every single feature in Windows. Now imagine doing that for every different edition of Windows (Home, Pro, Ultimate, whatever). Now imagine doing that again for every edition in every language.

Now imagine trying to do all of that quickly.

The upshot is that the cost of even the simplest of fixes is surprisingly high; thus, the decision to fix a specific bug is not a simple one.

And yet, all software has bugs

There's an old software engineering maxim that says a bug found by the customer is 10 times as expensive as one found by pre-ship testing; a bug found by pre-ship testing is 10 times as expensive as a bug found by the engineer writing the software, and a bug found by the engineer is 10 times as expensive as a bug found in the design before the software is ever even written.

In other words, the earlier that bugs are found, then the less expensive they are to fix.

So, you can imagine that there's a lot of pressure to fix bugs as early in the development cycle as possible. Indeed, there are untold thousands upon thousands of bugs that are fixed and never make it into the released product.

And yet, some make it through regardless.

That is the nature of software development. There's absolutely no such thing as bug-free software. Period.

It's also the nature of the incredible complexity of the system. There are days when I'm amazed that it works at all.

We want it perfect, and we want it now

All software vendors are in a no-win situation.

We complain about software that takes forever to arrive, and we complain about software that has bugs.

In the real world, those two things are at odds with each other.

It takes time and discipline to write and test software so that it has as few bugs as possible. Conversely, software that is rushed to market because people are clamoring for it is likely to have more than the average number of bugs.

We can't have it both ways.

Every software release - every software release, I don't care who it's from - is a compromise. I can pretty much guarantee you that there are engineers who are pleading for just a few more days to fix a few more bugs, and that there are marketing and sales people who are complaining that every day longer is resulting in massive market share or revenue loss.

The reality is somewhere in between. Some releases strike the right balance, others do not.

Where does that leave you?

I'm not trying to paint a bleak picture where bugs never get fixed - they do, just not all of them.

If you encounter something that isn't working as you expect definitely look for solutions, and if you have the ability report the problem if there are no solutions to be found. There's a tremendous amount of information and resources available on the internet (of which I hope Ask Leo! can occasionally be one ).

Just don't get overly frustrated if no fix is forthcoming. And don't immediately jump to the conclusion that it's being totally ignored - that's highly unlikely.

Instead, focus on finding workarounds or ways to avoid the problem. If it really is the Most Important Bug Ever for you, that might even mean switching to software from some other vendor.

Oh, and about Bill...

It always causes me to scratch my head when people rail against Bill Gates for perceived issues with Microsoft or its products. I'm not sure what it is about Microsoft that even today causes people to blame Bill personally for all its faults and failings.

Bill hasn't worked there since sometime in 2008.

And even when he did, he wasn't writing code and he most certainly wasn't examining and approving or rejecting individual bug fixes in products or making specific product design decisions.

In other words, he was never personally responsible for whatever feature it is that you don't like or the bug that you've encountered.

So these days, your ire at him is wasted, unless you happen to object to what he's doing with his philanthropic foundation.