How to design and structure a technical/programming Thesis

Question

I'm currently writing my bachelor thesis. The scope of this thesis will be approximately 25-30k words/80-100 pages of content.

We have only written literature reviews during the course of studies so far. My thesis, however, will be more technical: the thesis will be about an application that I develop.

Since I've mostly done literature reviews before, I have some doubts about the way I've structured/justified the thesis. While I have a (I think) general idea ofhow to go about this thanks to online research and talks with my advisor, I'm not entirely confident that I've understood the "big picture" of writing a thesis that focuses on the development of an application.

Most of the material I've reviewed that deals with application development is relatively short (<10 pages), so the structure of it is hard to apply in my thesis. I have the feeling that, if needed, I could cut down the thesis to about 15 pages. If I wanted to explain all the things that I did during the course of the development, however, I would probably need more than 200 pages.

My first question is: How can I find a good middle ground between those extremes?

Also, I'm a bit confused about how to formulate a solid "contribution to science"-argument for this kind of technical thesis. Going along the lines of "this hasn't been done so far in this way" seems lackluster. Something like "this application can be used by other researchers" also sounds a bit flat, especially considering that this is only a bachelor thesis.

The second question is therefore: How does a good "contribution to science" for this kind of thesis has to be formulated? Which points does it need to address?

Answer 1

You almost certainly should shift the focus - just a little. Do not despair, it's more of seeing everything from a different angle.

Writing a thesis about a piece of software you've created while working on the thesis is at any rate dangerous. As interesting as it might be (as a study in software engineering, maybe), it looks a little bit like researching a synthetic subject. Most certainly, no one else will publish "about your software"...

The time-honored approach is to present a hypothesis. Maybe it's about how some problem can be solved at all/faster than known before/much more elegant. To achieve a fair and faithful presentation, you will have to write a little about the approach of your predecessors in the field.

Now enter your software. For the written thesis, it's just a tool to examine your hypothesis. Writing about some major design decisions should be in order, as long as they are strongly connected to the possibility of testing your hypothesis.

After presenting your newly forged tool, you can delve into test results, and present if they actually support or weaken your initial hypothesis (if there are any surprising results, be sure to mention them, even/especially if they seem to challenge your hypothesis - anything that "will warrant further examination" is good news in research).

This way, you will have created a thesis on a more general subject (using your software as a research tool), and there's your contribution to science, too. Others can check your results, try out and compare their own approaches and so on. That's why your thesis should be about the problem and your proposed solution and it's properties, not about the tools you've created during that process.