Number of words: 687

A crisis came when software products got too big for one person to handle. MS-DOS 1.0 was largely designed, coded, compiled, and debugged by one auteur, Tim Paterson. As software products became more complex, dividing the labor between two or more developers became necessary. That was easier said than done. Chunks of code written by different people cannot be melded together unless the chunks are written with that aim in mind every step of the way. There has to be an ongoing dialog between developers and an efficient way of resolving the inevitable differences of opinion about the “right” way to do things. “Communicative” and “easygoing” are not words often used to describe the personalities of developers. Instead of communicating, developers wrote their code alone, in the middle of the night. This was a big problem.

One of the people called upon to tackle this problem was Charles Simonyi. Simonyi is a renowned computer scientist who has chosen to work in a corporate world that is sometimes suspicious of academics. At Xerox PARC, Simonyi wrote the first what-you-see-is-what-you-get word processor. He chafed at Xerox’s profound lack of interest in marketing the windows and mouse interface its own research lab had invented. During a business trip to Seattle, Simonyi dropped in at Microsoft without an appointment. The hiring was a little looser back then. An underling (Steve Ballmer) looked at Simonyi’s portfolio and decided that Bill should see it. Gates was in a meeting. By the time he was free, Simonyi had to catch his flight home. Gates rode with him to the airport. Their personalities clicked. Simonyi soon accepted an offer to come to Microsoft.

Simonyi’s solution to the multiple developer problem was to create a new job description called master programmer. Somewhat like a medieval craftsman, the master programmer would have full responsibility for laying out the program and writing the code. Working underneath the master would be a team of assistants. They would have the responsibility for debugging and optimizing the code.

The idea made a lot of sense. It too hit a brick wall, however, because of the unique personality of the typical developer. Everyone wanted to be a master programmer. No one wanted to be a code serf, as the assistants were called. Since there could be only one master programmer on a project (that was the point), the majority of developers were doing grunt work.

Thanks to Microsoft’s famous feature bloat, the master programmer concept was itself quickly stretched to the breaking point. Software products became too big for even one master programmer. Another problem was more fundamental. The master programmers weren’t always good at designing software. As software became more sophisticated, consumer-end design issues became ever more distinct from the nuts-and-bolt coding. Asking the same person to handle both was asking a lot. There may be great linebackers who are also great playwrights — still, if you hire someone for one thing and expect him to handle the other, you’re likely to be disappointed.

The term “master programmer” was never used much. It sounded too patriarchal even for a place full of screaming alpha males. They toned it down to the non-gender-specific program manager. That job title is now used throughout the software industry. But the program manager as we know it is largely the creation of Excel developer Jabe Blumenthal.

Like many Microsoft employees, after making a suitably large fortune, Blumenthal left the company to devote himself to suitably eclectic post-Microsoft careers. Blumenthal runs a paragliding school in the Cascade Range and teaches high school math and physics at his (and Gates’s) alma mater, Lakeside School. Blumenthal’s great inspiration was that a program manager doesn’t need to know how to program. He decided that the program manager should envision what a product is going to do and establish its look and feel. The program manager writes not code but a product specification (“spec”) detailing that vision. Thereafter the program manager’s job is to run herd on the developers, making sure they implement the spec and do it on time.

Excerpted from page numbers62-64 of ‘How Would You Move Mount Fuji?’ by William Poundstone.