What makes good research?

When joining my group, one of my PhD students got blamed by one of my colleagues: With her being best in class across all  theory courses, why would she "waste her talent" with a practitioner like me? Ah, the good old debates between theory and practice. As a researcher in software engineering, none of my work will ever be as elegant as what my colleagues in theory do, attacking the most complex problems with beautiful abstraction. But then, I know colleagues in theory who feel inferior to their more applied colleagues, because what these do actually has impact and interest in the real world.  

Obviously, different people have different ideas on what makes good research. But what are these categories?

Six years ago, I had a conversation with the founder of our faculty, Günter Hotz. Our faculty is well-known for its constant excellent hiring, based on ideas Hotz installed 40 years ago. So I asked him: How do you recognize good researchers? Or better: good research? To which he presented which I hereby name the Hotz model of good research:

It is actually fairly simple. There are three criteria, which are orthogonal. (He raised his hand, spreading off thumb, index, and middle finger at right angles to each other.) You ask the following questions:

First, was it hard? When you look at the research, is this something which required years of training and perspiration, or is this something anyone on the street could have come up with?

Second, is it elegant? Is this something which solves a specific problem, or is this something that you can apply over and over again to new problems?

Third, is it useful? Is this of value only to the academic community, or is this something people outside can use to create value or make money?

If you're good on one of the axes, you are doing good research.  If you're good on two axes, we'll hire you.  And if you're good on all three axes – well, I have yet to meet somebody who excelled in all three.

On this, he looked me in the eye and said:

Actually, now that I think of it, the "usefulness" axis is a fairly recent addition to the system.

There's a number of lessons to be learned from this. First, if your work was very hard, is very elegant, or very useful, you have every reason to be proud – and you deserve the respect from your fellow researchers, even if you don't share the same axes. In software engineering, usefulness is first and foremost, but truly hard or elegant work can still leave me highly impressed. If I get an idea of how it may be put to use, I feel struck by shock and awe.

Second, there is little chance you will be able to excel on all three axes. Usefulness calls for applicability in the real world, whose details will quickly spoil the elegance of your approach. Elegance implies simplicity, and simple is the antonym of hard – unless you claim it was real hard to get your approach simple. Making something really useful is hard, but was it a true intellectual challenge, or just a long engineering process? Difficulty, elegance, usefulness – pick any two.

Third, usefulness is still a recent criterion by academic standards, and as a new kid on the block, it may struggle to get accepted by traditional academics. But computer science has long left the academic ivory towers, and is progressing at a furious pace in the real world. As a young researcher, why limit your impact to dusty publications, or wait until the real world finally adopts your approach?

You have every right to choose the axis (or axes!) on which you plan to excel. Different people make different choices, but remember: The axes are orthogonal, and no axis dominates the others. The only important thing is to push the boundaries as far as you can. Face the hardest problems. Find the most elegant abstraction. Make it really useful. Push, push, push, with all love and respect. That's what makes good research.