Developers Should Write Papers

Many – but not all –  software developers would probably rather learn COBOL than capture and analyze in a research-type paper the systems they have constructed. But, contrary to popular belief, research papers are one of the best way to capture the important aspects of a system in a concise and usable form. All developers should write (or be made to write) a paper when they do something that is worth sharing with others. [A paper does not need to be an academic research paper. It could be a detailed blog post like Joe Duffy's Blog, which contains the equivalent information in a less formal format.] It cannot be a system architecture description – hundreds of pages of detailed, hierarchical description that no one can (or does) read.

Let me tell you a cautionary tale how Microsoft threw away $100 million, with little or no return, because developers said, “writing papers is not part of my job”. In Microsoft Research, Galen Hunt and I ran the Singularity project to write a modern operating system in C# . It was a highly visible project, both inside and outside of Microsoft, and Eric Rudder, a senior VP, was interested enough in our ideas to start a follow-on project called Midori to produce a production operating system engineered along the same lines. Midori ran for 4-5 years, employed up to 50 or so first-rate developers, and produced a working system.

The team was given the charter to build the system “right,” so they carefully thought about architecture, built innovative tools, measured and tuned, and were willing to discard and retry until something worked well. As expected, a team with this charter attracted top Microsoft developers, many at the partner level, who relished a chance to implement a new system from scratch with a strong engineering discipline. And, they came up with a large number of interesting, innovative idea about programming language support for OS and parallel programming, TCP stack implementation, building interfaces with functional reactive programming, how to build efficient systems in managed code, and many other topics.

But, pretty much all of this is lost (outside of Joe Duffy’s excellent blog posts. As the project was maturing, Galen and I repeatedly asked people to write down what they had learned, but the answer that we got was that they were developers and wrote code, not papers. Their intent, of course, was that we (Galen and me, the researchers they knew) should write the papers – they would happily share the (millions of lines of) code. This division of labor does not make sense. Neither Galen nor I had the time, nor did we know the details of the system and the many alternatives that were examined and discarded. We could write papers, but they would not be insightful, useful papers.

You can pretty much guess the rest of this story. The Midori project was cancelled, so many of the people left the company or went to other jobs, taking their hard-earned knowledge with them. Tragically, the brilliant architect of the project, Chris Brumme, died abruptly last year, a further loss as well.

What did Midori cost Microsoft? Assume a senior dev cost Microsoft about $500K/yr in salary and benefits and there were 40 such people on the project per year (I’m trying to be conservative). That’s $20M per year, for 5 years, or about $100M. Given the seniority of the people on the project, I would be surprised if it wasn’t far greater than $100M.

Of course, Microsoft still has the source code and filed some patents, but we all know how difficult it is to understand a new system of this complexity and how valuable patents aren’t. It would have been great for Microsoft to be able to point to a web page with 5 or 10 short and to-the-point papers talking about Midori technical innovations. Google has papers on its key technical innovations, perhaps because they embed PhDs in a product team not in a research lab.