Research is about revealing what no one has revealed before. It consists of some distinct non-linear activities: understand the domain, find a new idea, make it applicable, gather experience reports, validate it, educate your peers, and eventually get it used in practice.
In other words it is a fascinating endeavor, and like any fascinating endeavor it has its challenges. Given that research is about navigating uncharted territories, the most pressing challenge is how to know whether you are on the right track. Or, as Yoggi Berra once put it:
You’ve got to be careful if you do not know where you are going, because you might not get there.
Yoggi Berra
We should try as much as possible to assess where we are and where we are heading. The question is: what should the process of research be to make sure we do not lose our way?
Before we go further, let us first take a look at what are the forces that influence the research environment in academia.
The engine of research is not the Professor and it is not really the PostDoc. It is the PhD student because he is the one that has the time and energy to actually go through all the required steps.
The design of a PhD requires the student to formulate, to build and to defend a thesis that is distinct enough from every other thesis around. I call this a "two arms length" situation because it is similar to what we use to do in school before starting the gymnastics exercises: each of us would raise and spread our hands to make sure we are at least two arms apart from each other. Like this we were safe from injuring each other while performing physical exercises. In the same way, the PhD student must be two conceptual arms away from anyone around him so that he is safe. While this design ensures originality, given that PhD students are so distant from each other, it also does not encourage deep collaborations, given that being at two arms length prevents handshaking. That is the reason why most PhD students have a hard time finding collaborators and they end up working alone.
From another point of view, regardless of what people might think, research is a highly competitive world. As a result, we naturally tend to regard our piers as competitors. Accordingly, it follows that it is better to keep our work a secret until it is ready for prime-time. This line of thought again tends to push students to work alone in their own corner.
However, lonesome research is less then optimal because it implies that research efforts are predominantly invested into rather small topics. Furthermore, when we work alone we are left defenseless against our greatest enemies: our own assumptions.
There is a way to find collaborators. Not on the horizontal plane, but on the vertical one. Instead of looking for peers that are interested in exactly the same things as we are, hence our possible competitors, we can look for people that either need what we do, or can provide input to what we do. Collaborating along these lines leads to win-win situations.
The effective way of fighting our assumptions is to expose them to other people and to obtain feedback. No everyone can provide useful feedback, but those that are truly interested can. Demo-driven research is a process that has as a goal finding the interested people and obtaining their feedback. I decompose this process into 7 distinct basic pieces.
Science is about models. Models are a representation of the real world, and they help us grasp the world by presenting only the details relevant for the problem at hand. To get a PhD you must create a model. This model has to solve a significant problem and it has to be original.
Models tend to remain abstract. They look nice on paper, but when it comes to the crude reality, they do not apply because of nitty gritty details.
No matter how interesting a model is, it is still just about facts. And the fact is that facts are boring.
At conferences we get presented models after models, facts after facts, until we get to ask ourselves if the wireless network is still working. We just shut down. A shut down brain will not provide any feedback.
A good story, however, can capture interest. We learn through stories, we choose based on stories, and we even pay for stories. Stories are the way we perceive the world around us.
Your goal is to obtain feedback from interested people, but for that you need to find the interested people. Have a story together with your model. Get them intrigued. Get them excited. Get them interested.
Not any story will do. Too many times we are sold fancy stories only to find out that the essence is not matching the advertisement. Announcing what is not there will not get you far. People will easily see through, and even if they will not at first, they will not stay with you too long. Your goal is to build trust.
The role of a story is not to just to sell, but to exercise the model in another, more accessible language. Your story should reflect your model. Make them raise their brows, but do not embellish. Intrigue honestly.
Marketing is the art and science of telling a story about a product, and it is often viewed as being a cheap layer on top to make us buy something.
When I started my PhD, I wanted to build an analysis based on the metaphor of yesterday’s weather and applied it to predicting how software systems will change. That was the story, but when I tried to implement it the result was a rather incomprehensible two pages long piece of code. The problem was not that the computation was not right, the problem was that I just could not explain it to people. I tried to reorganize the code, but it just did not get any better. So, I went back to the model, introduced history a first class concept, and the implementation turned into a simple 5 lines of code. The concept of history as a first class concept became the very essence of my PhD thesis.
The relationship between the model and the story should be bi-directional, and you should not wait until the end to put a story on top of a model. The story development should be intertwined with the model.
At the end, just go and demo. Both the model and the story will grow. The most important thing is to overcome the basic fear of being exposed. When you go and demo, it will be just you, your model and your story. You will be naked. And so it should be.
When you demo, keep in mind that you are asking for the most precious of all gifts from people: their time and their energy. So, be sure you ask for permission. If they give you 5 minutes stop after 5 minutes and ask if they want you to stop or if it would be Ok to go on for another 5 minutes. If they do, then stop. If they want you to go on, ask for the amount of time. If they give you 10, then take 10. If they give you 1 hour then take your time and elaborate for 1 hour. If they give you 2 hours, then take 1:30 hours.
To be sure you can demo, your demo should be ready at any time, so always have the starting point ready. And once you have a running demo, freeze it (Oscar Nierstrasz).
When you have a running model, you are tempted to start with the latest and greatest idea that you came up with and built last night. At least I do. Of course, some situations ask exactly for such kind of demos, but in most cases it hurts more than it helps because what you worked on last night is not engineered and might not work on all situations. So, fight this temptation and show a frozen demo from last month that works. Remember, the main goal is to deliver the story to get the audience interested enough to get you real feedback.
These days, it is considered a must to accompany your deliveries with slides. There used to be a time when slides were called visual aids. "Visual aid" reveals the intention of the item, while "slide" describes the technology of the item. Perhaps, it is because we focused for so long in getting the technology right that we forgot about the intension. Slides are visual aids. That is, they are visual and they are aids. Just aids. So, do not use them as walls of technological defense because they cannot deliver the story. You are the only one that can.
Perhaps, counterintuitive, the most important part of a demo is listening.
When you demo, the attention is directed to you. It is an empowering feeling, and you might start to like it. The problem with this is that you will tend to emphasize the parts that make you look good. Your goal should be about gathering feedback, and not to create an image.
Listening is hard especially when the feedback is negative. We tend to hasten to present our side of the story. While this is sometimes useful, it is more beneficial for you to listen fully to what your audience has to say.
How do you feel about the comments from an email notifying you that your paper got rejected? If you are like me, you will tend to think that the reviewers were shallow and did not get it. Even if sometimes this is the case, it does not help anyone if you feel oppressed and continue to complain. It is much healthier to fight these initial bursts and concentrate on learning from the reviews as much as you can and try to improve your work and its presentation. And many times you will be surprised at how often even if the idea still stands, the presentation is not proper. I know I am.
You need to listen. One way to force yourself into doing it, is to remember that your greatest enemies are your own assumptions.
Feedback is a gift. Be happy when you get it, but do not forget to return it.
When you provide feedback, do not remain shallow. Get involved. Invest your energy and dive into all details you can get your hands on. Do not stop at the model. Look at the story, too. Form an opinion. Propose alternatives.
If done correctly, while providing feedback you get to observe from the outside how difficult it is to see obvious things from inside. You get to learn that the point of view is all that matters.