In industry it’s often pretty easy to know when to stop working on a project: you might get moved off the project, it might get canceled, etc. In academia, it’s less clear: I can stop working on something after half an hour, or else I can work on basically the same idea until the end of my career. This piece is about avoiding the problem of quitting a project too early; working on a project too long is depressing to see, but probably not interesting to discuss. Let’s look at a few anecdotes.
- About five years ago I was at an NSF workshop concerning high-confidence software for medical devices. The cool thing about this kind of workshop is that it mixes up attendees from academia, industry, and government. Anyway, this one very smart, well-respected researcher stood up and basically said “we’ve solved all the important system verification problems; you people just haven’t picked up the work and used it.” This really made my jaw drop: you’d be hard pressed to find even one problem in the area of embedded system verification that has actually been solved, much less all of them. Second, even for problems that are solved in some theoretical sense, this is like 2% of the real solution, which is giving people a way to verify real systems in a cost effective way. Anyway the implication that bothered me here is that the academic’s responsibility ends once the theorems have been proved.
- A few months ago I was chatting with Eddie Kohler and randomly asked him why he thought Click had been successful (my guess would be that Click is in the top 1-2% of most influential systems software projects from the past 20 years). His answer was simple: he kept supporting it. Of course there’s a lot more to it than that, but I’d imagine he’s onto something.
- Not too long ago one of my students got a piece of software working and figured it was time to move on a project he considered to be more interesting. This bugged me. I mean, there are only two cases here: either the project is irrelevant or else it matters to the world. If it doesn’t matter, why were we wasting time on it at all? If it does matter, then you need to keep working on it until you’ve made life better for the people who stand to benefit from the project. This means actually running the tool, seeing where it works and where it falls over, fixing areas where it doesn’t work, releasing it, evangelizing, and all that.
Am I claiming that academics should always productize their research and keep supporting it? No– definitely not. The ability to abandon any project at any time (subject to student and grant issues) is one of the great advantages of being a professor.
I’m arguing that the “generating ideas” part of research is over-rated. The important thing is to have just enough good ideas — one of my colleagues likes to say you only need a good idea about every two years — and then to build a competent research program based on those ideas. Learning when to quit and when to persevere is an important, under-rated skill. I’m not that good at this myself, having quit projects both too early and too late in the past.
3 responses to “Knowing When to Quit”
I think there’s an incentive structure problem that mediated against what you propose. Since as academics we are optimized for paper production, we find it easier to write new papers than do (HORRORS) what might be perceived as incremental work on an existing project.
I think as one gets more seasoned and the hunger for yet-another-paper abates, one gets a better understanding of the true nature of impact, and maybe more patience while waiting for a piece of work to develop.
I think researchers (including me) fall into the trap of “doing something intellectually stimulating” all the time. Maintaining code and evangelizing doesn’t cut it. Stanford especially does the job of marketing and evangelizing research very well, imo.
I think the same happens here in industry.
I spent 3 years working on a project – 1 year doing research on programming asymmetric multiprocessors, 1 year making the compiler more robust, producing tutorials for partners, etc. and 1 year productizing the compiler.
Turns out that I should have skipped the last year. What should have happened is for someone else to step in to productize the tools while I advise them. With me doing the productization, I wasn’t passing on my understanding of the problem, tools, etc. to someone else so any handover was just getting harder and harder.
(The project was part of a larger project which was cancelled at the end of that year. It’s not clear if we’ll resurrect my bit – but, if we do, it will probably end up looking very different.)