Recruitment of new hires, at first glance, doesn't seem like the sexiest topic, and my initial reaction to "Proudly Serving" was to wonder why Barr was spending so much time, right at the beginning of the book, focusing on Microsoft's hiring practices. But it turns out to be crucial. One of the key points to emerge from the book is that while Microsoft has many strong suits, it is weak on the creation of corporate methodologies that scale up as the company grows. As Barr points out, when your company is 5,000 people strong and growing by 10 percent a year, it's a lot easier to find the quality people you need than when you have 30,000 employees and are still growing by 10 percent. Microsoft, suggests Barr, has always had an attitude that if it continues to hire smart people, they'll be able to pull its collective fanny out of the fryer.
But now, Barr (who left Microsoft to take a "break" in the spring of 2000) says hundreds of job positions remain unfilled, and there's a sense that the "good old days" are gone. The hiring process itself, he notes, is set up in ways that may miss many qualified applicants.
Few people have ever seriously disputed the fact that Microsoft has a tradition of hiring smart people. What most critical readers are likely to bridle at is Barr's placement of "evangelization" at the center of Microsoft's success, rather than its leverage of monopoly power or other ruthless business tactics. "Evangelism," writes Barr, "means getting software writers at other companies to write code that works with your software." No company, argues Barr, has been better at doing this than Microsoft -- in large part because of its focus on preaching the gospel to software developers.
Specifically, evangelism means making sure programmers are aware of the way to interface their code with Microsoft's code. So Microsoft spends a lot of effort getting the word out about its APIs -- application programming interfaces -- to developers.
Proudly Serving My Corporate Masters
Adam Barr
Writers Club Press
342 pages
In this light, then, suggests Barr, the hundreds of millions of dollars spent on the rollout of Windows 95 were not aimed at raising consumer awareness. Consumers, he notes, were going to get Windows 95 whether they liked it or not, since it was going to be pre-installed on all new PCs. The point of the campaign, says Barr, was to convince software developers that Windows 95 was so big that they should devote their efforts to writing software to Win95's new 32-bit operating system. And on that count, writes Barr, it succeeded wildly.
According to Barr, "keeping third-party application writers happy, which helps the operating system sell, is more important than giving Microsoft's own applications an unfair advantage."
Critics of Microsoft, like myself, who are convinced that the company leveraged its monopoly over the operating system in illegal ways that essentially forced everyone to plug into Microsoft whether they wanted to or not, will be likely to take issue with Barr's contention that evangelism is more responsible for Microsoft's success than its sheer market power. But it's worth taking Barr's argument at face value, because it gives even more force to his observations about Linux and open-source software.
Linux, writes Barr, addresses "the two biggest concerns for Microsoft -- recruiting and evangelism."
"Linux does not 'recruit' per se; to contribute to the project, you have to provide some code, which is reviewed by other people. Thus a Linux 'interview' is a perfect simulation of working on Linux, since it is working on Linux."
Related issues, like the problem of retaining employees or getting rid of people, just don't apply.
As for evangelism, the availability of source code does its own evangelism. You don't have to buy a software developer's kit or get a certified Microsoft developer license to learn how to work with Linux -- you just look at the code. According to Barr, this is "perfect evangelism" -- although he does note that Linux has no equivalent to "evangelism Microsoft-style," an actively organized effort to encourage developers to write applications for it.
Barr is agnostic as to whether Linux will ultimately succeed in dislodging Microsoft from its position of operating system dominance. He sees just as good a chance that Microsoft will continue to improve its products and remain on top. But he is disappointed that Microsoft has, so far, been reluctant to experiment, in house, with software development strategies that might duplicate some open-source strengths.
It is that disappointment, ironically, which lends stature to the entire book. It would be all too easy to dismiss Barr's criticism of the antitrust suit as defensive, as a case of toeing the party line in classic "Borg" fashion. Instead, however, Barr's willingness to detail both Microsoft's flaws and strong points has the welcome effect of humanizing the company and ratcheting down the heated rhetoric that so often accompanies debate over Microsoft.
In a recent e-mail, Barr told me that he is now considering returning to the company, after a couple of years spent writing and parenting. After reading his account, I feel compelled to wish him good luck. Microsoft needs more programmers like him.