Tag Archives: research

When the Problem Is the Problem

This is the only thing I learned from my master degree. Asking the right question is half way done to get the right answer. In fact asking the right question probably more important than getting the right answer. Once you stated the question correctly, things magically fall into place and you can outsource the work to someone else.

Finding the right problem is half the solution
By Robert W. Lucky, July 2011, IEEE Spectrum

A problem well stated is a problem half solved.
– Inventor Charles Franklin Kettering (1876–1958)

We’re all fairly good at problem solving. That’s the skill we were taught and endlessly drilled on at school. Once we have a problem, we know how to turn the crank and get a solution. Ah, but finding a problem—there’s the rub.

Everyone knows that finding a good problem is the key to research, yet no one teaches us how to do that. Engineering education is based on the presumption that there exists a predefined problem worthy of a solution. If only it were so!

After many years of managing research, I’m still not sure how to find good problems. Often I discovered that good problems were obvious only in retrospect, and even then I was sometimes proved wrong years later. Nonetheless, I did observe that there were some people who regularly found good problems, while others never seemed to be working along fruitful paths. So there must be something to be said about ways to go about this.

Internet pioneer Craig Partridge recently sent around a list of open research problems in communications and networking, as well as a set of criteria for what constitutes a good problem. He offers some sensible guidelines for choosing research problems, such as having a reasonable expectation of results, believing that someone will care about your results and that others will be able to build upon them, and ensuring that the problem is indeed open and underexplored.

All of this is easier said than done, however. Given any prospective problem, a search may reveal a plethora of previous work, but much of it will be hard to retrieve. On the other hand, if there is little or no previous work, maybe there’s a reason no one is interested in this problem. You need something in between. Moreover, even in defining the problem you need to see a way in, the germ of some solution, and a possible escape path to a lesser result, like the runaway truck ramps on steep downhill highways.

Timing is critical. If a good problem area is opened up, everyone rushes in, and soon there are diminishing returns. On unimportant problems, this same herd behavior leads to a self-approving circle of papers on a subject of little practical significance. Real progress usually comes from a succession of incremental and progressive results, as opposed to those that feature only variations on a problem’s theme.

At Bell Labs, the mathematician Richard Hamming used to divide his fellow researchers into two groups: those who worked behind closed doors and those whose doors were always open. The closed-door people were more focused and worked harder to produce good immediate results, but they failed in the long term.

Today I think we can take the open or closed door as a metaphor for researchers who are actively connected and those who are not. And just as there may be a right amount of networking, there may also be a right amount of reading, as opposed to writing. Hamming observed that some people spent all their time in the library but never produced any original results, while others wrote furiously but were relatively ignorant of the relevant literature.

Hamming, who shared an office with Claude Shannon and knew many famous scientists and engineers, also remarked on what he saw as a “Nobel Prize effect,” where once having achieved a famous result, a researcher felt that he or she could work only on great problems, consequently never doing great work again. From small-problem acorns, great trees of research grow.

Like a lot of things in life, it helps to be in the right place at the right time. Sometimes all the good and well-intentioned advice in the world won’t help you avoid working on a dead-end problem. I know—I’ve been there, done that

network simulator

I have been sturggling with ns2 for the past 24 hours. ns2 is an open source network simulation implemented in tcl and C++. It suppose to be one of the most popular academic reseach tool in communication network. My problem right now is the compliation doesn’t seem right, when I run a sample testscript, it dies with a segmentation fault. I had tried different version under linux and cygwin without luck. Cygwin is another interesting open source program. It is like a linux emulator sitting on top of Windows, so user can compile and use unix/x-win softwares. If ns2 under cygwin still fails, I’m afraid to use brute force attack, fire up the debugger and figure out exactly what went wrong.


Today after the meeting with Dr. Hardy, on my way back to Burnaby on the skytrain, I gave some advice on research to first year grad student. I’m kinda surprise she does not even know how to use IEEE Explorer, yet already has a paper published in a conference. Internet really is the most powerful research tool, all you need is type in keywords, then the papers will magically show up. Actually one of the problems is there are the search result is too long. I really have to filter out the useful ones to be efficient. Using citation identify the “hub” that everyone else is referencing to is the key. Unfortunately I just know this method not too long ago, and wasted a lot of time reading useless papers.


When I am reading many journal papers this afternoon, I was wondering how many of those research paper are actually practical in reality? It seems many of them are just like my thesis, they are written for the sake of being written. I can’t convince myself what I am working on has any research value, rather it seems I’m just playing in a sand box, building my own version of overly simplifed reality. I guess that’s the difference between me and a true academic.