posted by Thom Holwerda on Sat 11th May 2013 21:41 UTC
Icon"Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.

The comment was originally posted at Hacker News, and was verified to be from an anonymous developer at Microsoft who works on the Windows NT kernel. He later deleted the comment, but allowed Bevand to repost it on his blog - but with the proof, "the SHA1 hash of revision #102", removed. It paints a grim picture of the state of Windows.

He claims Windows is indeed slower in lower-levels than Linux, and the root cause of the problem is "social". While Linux' open nature attracts developers working for glory and recognition, this is not the case within Windows - in fact, we run into something that has long been a problem at Microsoft: fragmentation. Windows development is managed by many different teams, and these teams do not work together at all.

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 means there's no incentive on working on small, incremental improvements, according to the Windows developer, because only huge improvements might get you credit - small improvements "just annoy people and are, at best, neutral for your career". This is the exact opposite of, say, the Linux kernel, where there is a continuous stream of small improvements and experimentation.

There are external issues as well - such as a talent drain to other companies, like Google. This means Microsoft has to rely more and more on people straight out of college, and these have no knowledge about why things work the way they work, and they are afraid to change things that do work. They then tend to recreate existing features instead of improving old ones.

All in all, it paints a not-so-pretty picture of Windows development. Since the blog post hit publicity the anonymous developer has had a few more words to say - the usual stuff in this scenario, trying to make it all a bit less harsh. Still, even with the harshness reduced, it ain't pretty.

It'll take a very strong manager to break down the walls and change all this, but you'd think upper management is aware of these issues and working on them.

e p (14)    221 Comment(s)

Technology White Papers

See More