The first things readers should know about "Proudly Serving My Corporate Masters," Adam Barr's account of his 10 years as a Microsoft programmer are a) he thinks the company got a raw deal from the Department of Justice, and b) he is pro-Linux.
That juxtaposition, which one would not automatically associate with the words "Microsoft programmer," is enough by itself to establish Barr's bona fides. A major reason so many people look askance at Microsoft is that so often its public representatives are feeding us a patent line of bullshit. But reading Barr, one never feels that he is making an argument purely to serve Microsoft's interests. We can disagree with him if we want, but we can't fault his sincerity or honesty. His willingness to flout the corporate party line on the pros and cons of open-source software makes his comments on the antitrust trial all the more believable.
Even more useful, Barr's account reminds kneejerk anti-Microsoftians not to reach for the cross and garlic when they hear the words "Microsoft programmer" -- as if simply being employed by Bill Gates automatically transforms one into an evil minion of the Dark Lord.
Programmers, regardless of who they work for, are defined by their willingness to submerge themselves in the arcane intricacies of code -- and there is a commonality to the resulting mind-set that often transcends whether they are working on proprietary code or free software, whether they consider themselves a hacker or a software engineer. Which is not to say that a Richard Stallman would ever be happy debugging Windows XP, but just to observe that there's more linking a Redmond developer together with, say, an Apache coder, than keeping them apart.
I realized this for the first time when I talked to a program manager for Microsoft's IIS Web server software four years ago -- he told me the Apache coders represented the "heart and soul" of the Internet. The problem is, Microsoft PR rarely let me get to the programmers -- and even that IIS program manager didn't want his name to be used. So instead I usually found myself seething as I listened to a flack tell me things that were so obviously self-serving as to be objectively insulting.
This is not the book to read if you want the scoop on Bill Gates, or insight on how to be a mover and shaker at Microsoft. As Barr writes, "I was never interviewed for any magazine articles, never had a press release mention my accomplishments, never participated in a meeting with Bill Gates." Nor is "Proudly Serving My Corporate Masters" the most eloquently written book about computing; it is not in a class, say, with Tracy Kidder's "The Soul of a New Machine" -- a book that Barr quotes several times. There are also some structural flaws -- his book bounces around from point to point across both time and space, with no clear narrative flow or overarching argument linking everything together.
But it is a heartfelt account of what it was like to be a programmer at Microsoft over an action-packed decade. Barr's detailed accounts of how complex software programs are constructed, and the various problems that plague programming, will strike a chord with anyone who is interested in technology and shine a light on the internal workings of Microsoft that is refreshingly different from the typical paean (or jeremiad) bestowed on the company by the press or business school academics.
"Proudly Serving" also has some acute observations as to what Microsoft has done right, and wrong, over the years. If there's an agenda, it is straightforward: Microsoft's success isn't the result of foul play or bullying but of hiring strong people and successfully evangelizing its standards and software.
And on both those counts, Barr is worried. Microsoft is no longer, he says, the "cool place where every college senior wants to work," yet its requirements for quality hires are ever-growing. And on the evangelization level, new challengers like Linux are making a case for themselves that poses a real threat.
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.
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.