My parents can’t get Microsoft Excel to work.

The symptoms was that after installing some other program, suddenly when they open a document they are greeted with a Microsoft Excel spreadsheet–but the entire content area is gray. No cells, no editing, no joy–just a large gray expance where the data should be. But the application is not frozen; oh, no. The whole thing seems to be behaving just fine, like a small puppy with a large candy stuck to its fur: the thing just hops around like all is well, despite the fact that there is this ugly red sticky mass hanging off its fur.

My usual recommendation in a situation like this: you’re hosed. Uninstall the entire application, uninstall the other offending application, and reinstall from scratch–and hopefully this will clear the whole mess up.

So my father tried this–no joy. Of course the results were different: he can create a new spreadsheet just fine. But try to open an existing spreadsheet–gray empty blob. The red sticky candy has somewhat been removed–but there is still a read sticky matted spot where there should be clean brown fur.

*sigh*

I hate Windows. And one of the reasons why is this sort of odd-ball DLL hell that Windows seems to infect all applications. Without ever having seen the source code to Microsoft Excel or this other application, I can tell you exactly what failed: there is some DLL somewhere, which was “upgraded” by the other application, which broke Excel. (The other application also provided spreadsheet-like functionality in one of its Windows, which makes me think they shipped with some DLLs used by Excel.)

And here’s the problem. In a large corporate environment we build our applications with tons of plug-ins: DLLs, Jar files, MacOS X Frameworks–and we do this because we want to either leverage code written by someone else without increasing the overall shipping footprint of our application, or because we want to minimize inter-team communications, which is the bane of any large software development team. (Because as we all know, team communications is essentially an O(N**2) problem–unless we can create multiple groups, in which case we can reduce this to a max(O(G**2),O(T**2)) problem with G*T = N, where G is the number of groups you’ve broken your overall team down into.)

We go along, we test our software, we see everything works, we ship. Job done.

Except… Well, except that, because three quarters of the code we just shipped is someone else’s, and because that code (in the form of frameworks, Jars, DLLs, whatever) can be replaced willy-nilly, with at best only a lose contract as to how those DLLs work, a lose contract that we may not have used correctly because some guy wanted to go home early rather than make his code more bullet proof, or because he didn’t understand the contract but by coincidence his code worked anyways… Well, you see where I’m going with this.

Someone ships an update to some plugin, which ships a new version of some DLL, and your code breaks in some subtle, bit-rottish sort of way. Something flickers before its drawn, or under some situations a file opened before some application ran causes a crash–the code you thought was bullet proof wasn’t all that bullet proof after all.

Windows seems especially prone to this problem: I don’t know of a single application that ships as a single, self-contained application. Every one of them breaks down into a million little DLLs, even if they are all Microsoft DLLs–and none of them are under your control. And worse: we’re encouraged to slam all of our DLLs in a common area (WindowsSystem or wherever), which causes the potential for bitrot to increase.

Your application isn’t rotting from the inside; it just seems like it.

A few years go by, the user has made compromise after compromise in their workflow–after having learned the hard way because of some weird DLL interaction on his system that he is supposed to shake the mouse like a voodoo stick before he is allowed to open his Word document–and something finally gives. The pile of crap dumped into WindowsSystem finally gives away, and the whole thing just dies a horrible, flaming death.

And the user, thinking that somehow it is his hardware that has failed (and not a pile of subtly incompatible software which caused his system to die), decides that, well, what the hell; perhaps it is time to replace my computer. After all, the computer is, as far as the user is concerned, behaving exactly like his car: after a few thousand miles, a filter needs to be replaced; a few thousand more, a gas shock needs fixing; a few thousand more, a gasket blows, and he is stranded by the side of the road.

We’re used to the idea that things rot, so we assume that our computers are also failing because of rot. But it isn’t rot–it’s a slow accumulation of slightly incompatible software causing things to die.

When I was at Microsoft for a few weeks I discovered that many people there simply reach out to a global server where all of Microsoft’s product lives, and they just blow away the entire contents of their computers and reinstall what they need from scratch.

End-users cannot do this.

And I think that’s why I hate Windows: because this bug, this defect, this software error, which could be solved by preventing third party applications from installing DLLs in a shared directory, causes the computer to behave exactly like an old creaky car–which encourages users to replace their computers every few years rather than just reformatting the hard disks of their existing (and perfectly good) computers.

It’s a software design defect which makes Microsoft money.