Information Technology Reference
In-Depth Information
projects leave some people dissatisfied, while others are excited by the possibility of
a leap into the future.
When evaluating a problem, a factor to consider is the barrier to entry, that is,
the knowledge, infrastructure, or resources required to do work in a particular field.
Sometimes it just isn't possible to pursue a certain direction, because of the costs, or
because no-one in your institution has the necessary expertise. Another variant of the
same issue is the need for a codebase, or experience in a codebase; if investigation of
a certain query optimization problem means that you need to understand and modify
the source code for a full-strength distributed database system, then possibly the
project is beyond your reach.
As research fields mature, there is a tendency for the barrier to entry to rise: the
volume of background knowledge a new researcher must master is increased, the
scope for interesting questions is narrowed, the straightforward or obvious lines of
investigation have been explored, and the standard of the baselines is high. If a field
is popular or well-developed, it may make more sense to explore other directions.
Project scale is a related issue. Some students are wildly ambitious, entering
research with the hope of achieving something of dramatic significance. However,
major breakthroughs are by definition rare—otherwise, they wouldn't be major—
while, as most researchers discover, even a minor advance can be profoundly reward-
ing. Moreover, an ambitious project creates a high potential for failure, especially in
a shorter-term project such as a minor thesis. There is a piece of folklore that says
that most scientists do their best work in their Ph.D. This is a myth, and is certainly
not a good reason for tackling a problem that is too large to resolve.
Most research is to some extent incremental: it improves, repairs, extends, varies,
or replaces work done by others. The issue is the magnitude of the increment. A
trivial step that does no more than explore an obvious solution to a simple problem—
a change, say, to the fields in a network packet to save a couple of bits—is unlikely to
be worth investigating. There needs to be challenge and the possibility of unexpected
discovery for research to be interesting.
For a novice researcher, it makes sense to identify outcomes that can clearly be
achieved; this is research training, after all, not research olympics. A principle is to
pursue the smallest question that is interesting. If these outcomes are reached early
on, it should be straightforward, in a well-designed project, to move on to more
challenging goals.
Some research is concerned with problems that appear to be solved in commercial
or production software. Often, however, research on such problems can be justified.
In a typical commercial implementation the task is to find a workable solution, while
in research the quality of that solution must be measured, and thus work on the same
problem that produces similar solutions can nonetheless have different outcomes.
Moreover, while it is in a company's interests to claim that a problem is solved by
their technology, such claims are not easily verified. In some cases, investigation of
a problem for which there is already a commercial solution can be of as much value
as investigation of a problem of purely academic interest.
