“You work a lot and [think], ‘Oh, gee, I don’t know anybody and the few people I do know are busy. So I’ll work some more.’ You keep working, you know less people, you do less things. Then pretty soon all you have left is work.” Then even work seemed hollow and uncomfortable, becoming a haunted house that maintained a strange hold even as he desperately plotted an escape.
These machines, which were designed to crunch numbers, were treated with skepticism and sometimes hostility because they symbolized regimentation. Computers seemed to bend humans to their will, forcing men and women to do little more than tend smart machines.
Programming “was just the most bizarre situation, because you’re used to doing something and thinking you’ve done it right,” he later said. “But it isn’t right. You just don’t notice it isn’t right. On a computer there is no consolation in discovering you’re almost right. Almost means you’re still just wrong.”
For fifty thousand dollars, Gates bought the program, without telling the author of IBM’s interest. Later, some called the purchase “the deal of the century,” but steal of the century was more accurate. Gates always denied that a great crime lay behind his fortune, but if one did it was his purchase of DOS.
Gates wanted to avoid a situation in which professional managers, with either no programming experience or out-of-date knowledge, held sway. It was destructive to rely on management pros to run software teams—or the company. They could not distinguish a promising program from a bust or evaluate schedules or product designs. At companies run by professionals, managers almost always came to mistrust their programmers, whom they could neither understand nor control.
Cutler brought his own religious ideas to networking. He thought Novell’s Netware crashed too often and lacked the means to keep intruders from commandeering files and printers. He thought people would flock to an operating system that made networks reliable and secure, even if they were slower. Rubin felt Cutler was mistaken. Customers were concerned about the speed of their software above all else.
Cutler actually thought testers were worse than that. Their mere presence, he felt, fostered the dangerous illusion that someone could save a programmer from his sins. Cutler wanted a programmer to test his own code. The rationale for outside testing, of course, was that the code writer had a vested interest in making his code look better than it really was. After slaving over a program, he might not show the honesty required to fully expose errors.
Manheim told testers to dig into a flaw, studying it deeply before filing an official “bug report” on the code. Programmers lived to shoot down such reports as a consequence of a tester’s feverish imagination, so Manheim encouraged as much deliberation as possible before filing them. “This kind of attention went a long way toward raising the respect [code writers] showed us,” one said.
Even though it contradicted his rhetoric about the need for a single software standard, Gates was prepared to tell IBM: “There’s no reason to think two [program personalities] can’t be of equal importance” to customers. This was a bold stroke. By denying reality, Gates’s tactic would freeze IBM long enough for Microsoft to install Windows as the standard for computing. Gates would peddle this apparent compromise to IBM and rival software makers, while Maritz and Cutler’s team pursued the real objective internally.
“We mostly hire people who have to be constrained, not motivated,”
Gates had a notion that only solid code writers should manage and all managers of code writers should keep writing code. This was a wonderful antidote for the illness that afflicted most software companies, in which managers were prisoners of their programmers. Schedules were missed, products failed, budgets were busted—all because the people on the top never could figure out what their modern-day wizards had done.
quite a few men among the NT team enjoyed viewing nude images on their screen. A program controlled the appearance of the nudes, which tended to appear when the PC was otherwise idle. Too often, Stowell and other women found themselves visiting a male colleague to talk about code, only to find another woman’s breasts pictured on the screen in front of them.
Part macho stunt and part common sense, the “dog food diet” was the cornerstone of Cutler’s philosophy. “We’re going to run on the program we build,” he insisted. Eating dog food meant there would be no escape from facing the flaws and imperfections of NT. Even while immersed in his own piece of NT, a code writer would confront all of its weaknesses. By controlling the operations of a code writer’s computer, NT would define the quality of his life. If at first NT tasted no better than dog food, all the better. Code writers would feel an urgent need to raise the dietary level by quickly fixing the errant code and writing more durable code in the first place.
He saw the Cairo project as the successor to NT and the means of realizing Gates’s goal of “information at your fingertips.” This slogan neatly encapsulated the future of computing, according to Gates. He imagined people leaving behind a world in which they retrieved information by mastering applications. While applications were powerful, they made people chop information into separate boxes.
“With software, you know what you have to do,” he said, “but it’s always a big surprise how long it will take.”
“Microsoft’s theory is if it takes two people to do a job, hire one,” Shannon explained. “It’s a stated policy. I’ve seen it in memos. It’s called the N-minus-one policy.” In the abstract, the approach made good sense. For all the complaints about workers lacking initiative, most bosses disliked employees who did too much or broke with tradition or set their own priorities. At Microsoft most managers, finding themselves shorthanded, had no choice but to let their people run away from them. Smaller numbers of people, especially on a huge project such as NT, made communications between teammates easier. And it helped the bottom line.
Throwing more people at the problem wasn’t an option, Perazzoli decided. The knowledge shared by Miller, Kimura and Andrew was so arcane that adding two or three newcomers to the group might actually halt progress altogether. “It probably will make them even later,” Perazzoli believed. The veterans would spend so much time tutoring the novices that they would lose track of their work. And by the time the new hires learned enough really to help, the group would have missed the deadline anyway. “For the same reason,” Perazzoli said, “your wife’s not going to have a baby in three months if you give her two more people.”
“Rick’s approach was doomed to failure,” Muglia said. “He took Cutler’s code, modified it and said, ‘Here, this is better.’ Of course, that pissed Dave off.” In Muglia’s view, this was a classic battle between the idealist and the pragmatist. “Rashid thought like a scientist. He thought about what’s possible. He made the kernel pageable and said, ‘Let’s see what breaks.’ Those things that break, we won’t make pageable.” By contrast, “Cutler weighed the situation as an engineer. He wanted to design the solution in advance—figure out beforehand what’s pageable and what isn’t—because that’s how you achieve robustness.”
Whatever failing prompted Cutler to mistreat people, his capacity for blocking out the ordinary distractions of life was his road to excellence. People rarely achieved greatness because they were too blinded by daily routine even to try anything extraordinary. For Cutler mediocrity was a failure of will, not talent.
Bugs were inevitable; they were born of flaws harbored by every human being. To avoid bugs altogether, “one must perform perfectly,” and people never did. On the “woes of the craft” of code writing, computer scientist Frederick Brooks has written: “If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjustment to the requirement for perfection is, I think, the most difficult part of learning to program.”
A quarter century since the first fissures were spotted in the edifice of Bigness, it is now fashionable to dismiss big organizations as dinosaurs, incapable of managing complexity. It is hard to argue against specific examples. But this does not mean that small organizations are by definition the answer to the challenge of complexity. While the entrepreneur and the lone genius are rightly celebrated as engines of creative destruction, “small is beautiful” is a false cure for the Bigness disease. The really grand dreams of humanity increasingly require immense resources and armies of skilled people; however nimble, small agencies are ill equipped to marshal the required people and resources. Nations, no less than corporations, are becoming more reliant on organizational expertise even as faith in large organizations vanishes.
Many technical teams, while encouraging conflict, spawn bureaucracies. To protect themselves against incorrect decisions, they form committees to weigh important matters. These committees spawn subcommittees, and before long a straightforward proposal is subject to a lengthy review by people who aren’t actually doing the work. The NT team never fell prey to this stultifying process. The team’s one regular meeting occurred each morning, and usually only managers attended. Meetings of the entire team were rare. Most technical discussions unfolded casually, and code writers usually held sway over their work. Outside review came only sporadically.