Microsoft's Flawed Customer Service Culture

I've griped before about how frustrated I am about the "state of the art" in software issue resolution in the IT industry. This typically involves unskilled "technicians" grubbing around in software "manufacturer" "knowledge bases", blogs, and message boards, reading wild speculation written by people who may not actually understand how the subject software works, and who certainly don't have access to the source code (and probably couldn't interpret it if they did). I'm not proud to work in an industry of cargo cultists, alchemists, and idiots.

Eric Fitzgerald has a posting that really raises my ire. I've spent some time writing software to aggregate and generate real time notifications from Windows event logs, as of late. I've been frustrated at the lack of comprehensive documentation for the different events that can be generated by Windows, and astounded that Microsoft can't put together documentation on all the events that Windows itself can generate. I mean, it's not like they don't have the source code.

So, with that in mind, Eric says:

This just makes my blood boil. I'm sure that Joe Anybody inside Microsoft can't just go hop into the source code to Windows / Office / etc anytime they want to. I'm also sure, however, that the ability of a Microsoft employee to actually talk to a developer with source access (and, possibly even a developer working on the part of the product they're interest in) is a lot greater than my ability to do the same.

Accurate, thoughtful, and well written documentation about the behaviour of a software product is the best Customer service tool that I know of, next to access to the source code itself. My supposition has always been that Microsoft employees don't understand what it's like to work in a world where source code access isn't available for key infrastructure components, like TCP/IP stacks, filesystems, and hardware drivers. They live in an insular world where they have quick access to these things, and where knowledgeable personnel are an email away. Eric's posting serves to confirm this supposition nicely.

Because Microsoft employees work in this environment, they appear blinded to what it's like to work out here, in the real world, where we have little or no visibility into the inner workings of closed-source software, and no ability to affect change when that software doesn't do what it was promised to do. Microsoft may eat its own dog food, but its employees certanly don't have to clean up the dog's mess.

When I run into one of these areas where "the spec" and "the code" don't agree, I get to play "knowledge base roulette" (or, at the best, "debugger and symbol file roulette"), while a Microsoft employee can actually do some meaningful research. Because Microsoft corporate culture doesn't value writing detailed, thoughtful, and comprehensive documentation (and because they produce closed-source software), I get to look like an idiot in front of my Customer as I bungle around searching for answers, instead of just getting out the docs (or the source code) and solving the problem.

Sure, I could pay Microsoft to provide "support" for software that I already paid them for to begin with. For some reason, though, I feel pretty strongly that I should be able to pull out the docs and figure out what's going on. (It makes me thankful I didn't give Microsoft any more money to upgrade my MCSE certification to Windows 2003. You don't ever look much dumber than when a Customer says "But you said you were a Microsoft Engineer something-or-other. Why can't you make it work right?")

And why should Microsoft bother to write better documentation, anyway? As long as Customers are willing to accept that they won't ever receive quality documentation, and are willing to pay for support incidents associated with bugs and deviations from written specs, the vacuum created by this lack of good documentation actually creates revenue for Microsoft! It's a win/win situation for... well... erm. It's a win situation for Microsoft shareholders!

While I'm on the subject, why would "the spec" and "the code" not agree? Seems like bush-league software engineering to me. Maybe I'm just out of touch, because the only software projects that I've worked on have been for medical devices. When requirements changed, we updated our specs before we went off hacking on code. Our specs were vastly more important than our code. I can't imagine writing software (other than one-off scripts) any other way. (I am regularly amazed at the amateurish mistakes that an organization as big as Microsoft makes...)

The answer to all this, I think, is for Customers of Microsoft, and all the other software companies who have similar culture, to stand up and let the companies know how they feel about this. Using open-source software that directly competes with closed-source alternatives is one great way to do this. Complaining vociferously in public forums, blog postings, and articles is also great. As I see it, those of us who work as consultants, especially, need to let our Customers know that they don't have to accept things as being "just the way they are". If a couple of my Customers spent 25% of their annual anti-spam licensing fees, for example, on paying a portion of a developer's salary to hack on open-source anti-spam software, they'd see improved support response (Gee-- it took Symantec over a month to resolve a critical buffer overflow issue in an "Enterprise" product...) and more customized functionality. It'd be wild to see some Fortune 500 companies siphoning a small percentage of their yearly Microsoft Office licensing budget into OpenOffice.

For my part, I'll keep being angry, and I'll keep telling everybody I can, anytime I can, about why I'm angry and why they should be angry, too. I'll keep using open-source software everywhere that I can, and I'll try and spread the word about these alternatives to closed-source software companies with flawed cultures of Customer service.