Why Microsoft creates buggy software inefficiently
We’ve all heard that Microsoft software is buggy. Bill G. says this is just because so many people use it they find all the bugs and so they get more attention, plus there are those who just enjoy pissing on MS. But I just had the experience, for the first time in a decade, of programming for Windows. The bottom line is that the entire environment is so buggy, flaky, and poorly documented that it’s a miracle anyone can write a program for Windows which runs at all.
Bill says that the open-source model can’t work because there’s no economic incentive to produce solid software or support it. What I realized is that he has it exactly backwards. The MS software development model can’t produce good software because it’s corrupted by the need to get the next version of the product out the door. Good software periodically and suddenly requires being rearchitected, or “refactored”, as they say, at inopportune times from the standpoint of the CFO. With the MS model, there is never a reason to take the time to go back and build the software right.
The elegance of the MS architecture has gone steadily down since Windows 3.1, which although kind of funky, at least had a weird predictability and consistency about it. Now, there are layers upon layers of additional libraries and wrappers on top of it, each
documented more poorly than the last. The only way to use the MS docs is to search them using Google, and even then it is all too often the case that you just can’t find what you are looking for, or worse—it’s wrong.
Programming in the MS world uses the approach I call “throwing mud at the wall”. Basically, you throw mud at the wall and see what sticks. You can never figure out the best way or the right way to do something in advance so you just try all the ways and use the first one that works. It’s like playing “pin the tail on the donkey”.
A good architecture has the characteristic that it surprises you from time to time with the cool things you can do easily because of its superior design. I’ve yet to come across a single thing in the entire Windows architecture that gave me this feeling.
Just a couple of quick examples, all from the browser extension world, which is what I was working on.
- The MS docs refer to an API to manipulate your browser’s history list. They give the name of a header file you use to access the API. But this header file exists nowhere in the world, except in a non-MS version that you can find on the net that was reverse-engineered by some poor sap who had no choice.
- A key ATL library used for internet access is just missing the wide-character version of the interface needed to read a web page off the net—making the entire app fail to link. I finally found this info in the MS knowledge base—with no work-around given,
of course. - Using the technique suggested to take the user to a particular web page after running the installer—namely a one-line VB application—polluted the entire installer with “.NET-ness”, which persisted even when I removed the VB app, requiring me to rebuild the installer component from scratch.
- The HTML DOM API provides a W3C-compatible “text range” object to represent ranges of text within a web page. But it is so buggy that something as basic as moving and endpoint of a text range forward or backward by one character doesn’t even work. And operations on a text range corrupt the DOM.
- The DOM built by IE is not even well-formed to the extent it sometimes cannot be walked from start to end.
- The API uses multiple interfaces for the same thing—four different interfaces for windows, for example—and of course the documentation is structured so you can never find anything unless you knew what you were looking for before you started.
And so on, multiplied by ten or a hundred.
What’s surpising, then, is not that Microsoft’s software has as many bugs as it does but that it doesn’t have many, many more; not that their software is often late, sometimes by years, but that it gets released at all. And I suspect that the high levels of profitability deriving from Microsoft’s near-monopoly in many markets is hiding the fact that it is well behind even other commercial software companies in development productivity because of the abysmal state of its architecture