Windows developer says kernel dev being mismanaged

Anonymous developer on Windows kernel team attributes Windows' slow performance to infighting, turnover, and mismanagement at Microsoft

In a litany almost as old as software development itself, a Windows kernel developer posted a scathing rebuke of the way kernel development is being managed. His observations have struck a resonant chord among developers in many disciplines: The problems aren't unique to Microsoft or to the Windows kernel, but the situation he describes is certainly damaging and desperately needs to be resolved.

It all started as a post on the Hacker News forum from ace programmer Marc Bevand, bemoaning the fact that the Windows kernel runs so much slower than Linux. "I can't even remember the number of times I have written a multiplatform program in C or Java that always runs slower on Windows than on Linux, across dozens of different versions of Windows and Linux," Bevand wrote.

An anonymous poster commented on Bevand's thesis. One qualification set this poster apart from the others: He claimed to be a Windows dev who contributes to the kernel, and he provided information about an as-yet-unreleased kernel file that seems to confirm his claim.

Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening. The cause of the problem is social. There's almost none of the improvement for its own sake, for the sake of glory, that you see in the Linux world... There's no formal or informal program of systemic performance improvement.

He goes on to describe a work environment that's a developer's nightmare -- but the situation is one that I hear about over and over, both inside and outside Microsoft. In a nutshell, here's what the anonymous poster says:

  • There's no corporate mandate to improve kernel performance.
  • Dev teams don't want outside patches: "There's just no incentive to accept changes from outside your own team."
  • Small changes, with cumulative benefits, get no notice: "Incremental improvements just annoy people and are, at best, neutral for your career."
  • Microsoft is having trouble retaining talented people, and newcomers just don't understand the nuances: "[O]ur good people keep retiring or moving to other large technology companies, and there are few new people achieving the level of technical virtuosity needed to replace the people who leave."
  • There's a tendency to implement new features -- which get recognition -- instead of improving existing features.

Over the weekend his comments drew a lot of fire, and the anonymous poster submitted a retraction of sorts. "I was much too harsh, and I didn't intend this as some kind of massive exposé. This is just grumbling."

Well, yes, it is grumbling -- but it also paints a picture that's all too familiar to anyone who's worked in the software business for a while. Monolithic systems are hell to maintain and improve, and much of the problem arises because the devs involved get caught up in problems precisely as the anonymous poster described. Although it must be noted that he didn't mention status reporting and performance reviews, two other gripes that seem to get louder with more mature companies and giant products.

Is there a solution? Debatable -- and the debate's been going strong for a couple of decades. One thing's for sure: smaller, lighter, less encumbered systems have an enormous advantage. Perhaps, ultimately, that's the moral of this story. The problem isn't so much that Microsoft's doing a bad job of improving kernel performance. The problem is that other alternatives, which do less and do it more efficiently, are rolling over the old guard. Even the smartest people in the world -- and Microsoft's chock-full of them -- will ultimately hit a dead end improving buggy whips.

This story, "Windows developer says kernel dev being mismanaged," was originally published at Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow on Twitter.