Surviving the contribution requirements

Question

How can one write a thesis in Computer Science, without actually providing the solution, but researching it and explaining how it's being solved right now but not for the specific problem (research area) identified by the researcher.

For instance, imagine that you spend your first year doing a literature review on the subject matter.

Now in your second year you're expected to build this solution, what if you cannot build it, or it requires too much code/time/investment. Obviously, I'm going to try to build the solution, but what if I fail building it, because it will require a lot of advanced code and algorithms.

Is there a way to survive that? Are there methodologies that can be used when you have done a literature review, and then tried to build a solution, potentially failed.

How can one continue and research the topic, write the thesis, or even get published, without having all the code to a solution? Will graphics/images combined with some kind of methodology be a way of actually conducting that research?

Very anxious and need help, motivation and support in order to know how to tackle that period when building the solution is required.

Answer 1

For a doctoral dissertation (I missed the tag, initially), there is probably no way out. I suspect that there are very few doctoral programs, world wide, that will give you a doctorate for a "faithful, but failed, attempt".

The solution is to, sadly enough, pick a different problem, perhaps related to the original, but which is more amenable to solution.

However, if you are doing "real" research and not just going through the motions, there are no guarantees. Research is about the unknown and the unknown can be tricky to reveal. It can be very elusive.

In my dissertation days, I worked on three problems (three bears style). The first was too easy and I could develop a theorem and its proof just about every day. I got a lot of results in a few weeks, but it failed the test of significance. Cute, but it was abandoned. The second was too hard and I couldn't scratch the surface of the diamond/titanium like coating that cut me off from the least result. Also abandoned.

The third problem was just right. Hard, doable, significant (to a very tiny audience, of course). But had I beat my head against the second problem I'd likely still be there almost fifty years later. (Oldest living grad student emerges from dusty cave to say "nope" once again.)

Talk to your advisor. Work out an option for a different problem. It would be good if it were close enough to the original that your literature search gives you tools for the attack. But there is no guarantee. The unknown is the unknown until it becomes known.

Answer 2

Is there a way to survive that?

Yes, there is. Daniel Hatton has hinted at it but I'll elaborate.

During your research, there will be many failures and "schedule overruns". Thankfully, this is expected in academia - you are dealing with the unknown, after all. However, if the part you have failed at is actually already done by someone, it rapidly becomes lot less forgiving: a PhD in biology might be expected able to do titration, whimsical as the materials might be, and a PhD in CS might be expected to glue together some code and write something on their own. That gets you into "no guts, no glory" territory - there will be some risks to be taken, and your past experience shall guide you through it. It is very common to have both under- and over-estimates of problem complexity in your career.

The trick here, of course, is to turn "failures" into "wins". Related: this, this, this and this.

While you are dealing with big unknowns there in terms of time estimates, you still get paid for it. And are expected to be able to show some results for it, start to end. That means seeking alternatives and always having a plan B (C, D...). Writing the code turned out to be too hard? How else could you show the merit of your results? Maybe instead of glorious solve-all code you might be able to solve a couple of oversimplified cases which would make writing relevant code lot easier? Maybe you could do some analytical work instead (it would likely take lot longer than writing code but still)?

Bottom line - you may cut your work short and not cover everything that was originally planned but you still have to make sure your work is complete. What this means actually is a pretty specific approach to planning in the first place - you ought to seek these extra exits and don't just hope you'll ride the highway from start to end in more or less given time. The PhD is, in large part, exercise in precisely that.