Why is Windows slow? and a letter to Sally

There’s an interesting article roaming around the interwebz these days regarding the performance of Windows, and why you don’t actually see the improvements (that may be spectacular at times) from the open source world. It’s an interesting comment, worth reading for any developer. But the most interesting thing about it is not about the specifics of the disgruntle of the writer. I am certain he doesn’t really feel that way, but, caught in the moment, he spurted all those things (as a matter of fact, he retracted the harshness of some of his statements in a later comment, included in the article itself).

The most interesting thing about this article is his description of the organizational structure of the corporation which tends to be counterproductive when it comes to large projects. And this is why this article caught my eye; in fact, it was the comments of Thom Holwerda from OSNews that made me write this article. But first, the original comment of the disgruntled writer:

Component owners are generally openly hostile to outside patches: if you’re a dev, accepting an outside patch makes your lead angry (due to the need to maintain this patch and to justify in in shiproom the unplanned design change), makes test angry (because test is on the hook for making sure the change doesn’t break anything, and you just made work for them), and PM is angry (due to the schedule implications of code churn). There’s just no incentive to accept changes from outside your own team. You can always find a reason to say „no”, and you have very little incentive to say „yes”.

This is the essence of what being a big place means. It’s impossible to have an organization of Microsoft’s size without having this. Why? How could you? From the management side, you have people working for you 9-5 which you have to pay and, more importantly, people that justify their earnings. How? Improving old code by 5% doesn’t sell more, doesn’t improve your image dramatically. This is why Apple doesn’t come year after year to say: This is just the previous phone, the same software, only 5% faster when you’re picking your nose. No, they have to come and say that this is THE NEW WAN! and it’s made of magical unicorn poo or something.

And even if, thinking in absurd terms, managers would stop for two years from chasing magical unicorn poo, and say: let’s improve this by 5%. The point of the Microsoft guy that wrote the article would still not be fulfilled: you’d have the same people looking at their own code. For non-developers, you have to understand how this feels like: think about re-reading the same e-mail you wrote three years ago, and starting to bash your head and try to improve the writing in which you tell Sally that you liked her in the most boring play you ever seen. Without changing any of the existing words and phrasing, because it will break the experience of Sally reading the mail. Yeaaaaaaaah. Exactly like that.

And it’s not only that. If you ask one guy to do one thing, there’s little reason that the second time he will do things differently. You need a real exchange of ideas, with vivid understanding of ways to improve things. You need a high level of communication… a level of communication which is next to impossible to reach in a two-people partnership. How could it work in a thousands-of-people structure?

Microsoft’s Windows is a remarkable piece of software, exactly because it was a viable product created in the conditions of a large corporation. You think only Microsoft writes software that bloated? Have a look at His Bulkiness The Android. So yes, Windows is a remarkable piece of software, but they had a ton of very smart people, that pretty much explains it.

How does a developer feel when he’s welcomed in a large structure like this? Well, just like this guy. You get very frustrated with your inability to change things, and you find out that if you want to change something it’s probably because you don’t really understand why it got there in the first place. Go fix the letter to Sally that someone else wrote.

And by the way: it can be easy to fix that letter to Sally. You () only* have () to {create proper accolades, prepare for change, … } the text1 with† {footnotes, parenthesis, ellipsis, …} from the start.

It may not make sense, but, after a while, Sally will get what you meant. But she never opened the letter anyway. She doesn’t like engineers, she prefers doctors. Or lawyers.