[h0cked]

If your goal is just to producing quality papers, this is perfectly great. If your research involves systems and implementations, it sucks to have to write every bits of code yourself. I don't think CS research is just about theory, at least not the line of research I am doing, I am all about making it readily available to others to use.

[_delirium]

Yeah, it certainly varies. I'm in AI, which is a bit different from systems. A lot of the work is based on existing open-source code, since you don't need to (probably shouldn't) be constantly reinventing the wheel. In my case it's usually the modeling, data analysis, and insights gained from the data that's new, not the underlying software (e.g. I wouldn't write an SMT solver myself).

When I do produce code, I produce prototype code myself or working together with masters students. When the goal is to produce robust, end-user-ready software, I prefer one of two approaches: 1) work within an existing open-source codebase, contributing improvements upstream; or 2) collaborate with a company to turn a prototype into something polished and end-user-ready. Even if I had a bunch of funding, I don't think I'm in a good position to produce and maintain polished end-user-ready software. Academic software has a habit of going unmaintained when the PhD student graduates or the NSF/EU project ends, and research funding isn't really aligned with production needs. John Regehr talks a bit about that here: http://blog.regehr.org/archives/1058. So I tend to stick with either one-off prototypes, or find a way to collaborate with someone (open-source community, company) that is better positioned to maintain software.

Other decisions are also perfectly valid, just given resources and interests I don't see maintaining essentially a software-production company within academia, with paid staff, as feasible for me personally.