Learned from writing my thesis

Filed under: research — Tags: , , , — thomas11 @ 22:36

A few weeks ago, I submitted my Master’s thesis.  I was aware that writing such a large report (120 pages) has its own pitfalls, so I read some of the advice collected by Tao and Yuan Xie and tried to always keep in mind some of the rules of good writing. When I look back on it now, I think it came out reasonably well (the grade suggests that, too). However, I still made a couple of rather serious mistakes in writing that my advisor Heiko recently pointed out to me. I don’t know if this will be helpful to anyone, but publishing them will help me memorizing them.

  • An abstract must always address five points: The field of research in relation to the conference/the journal), the problem and why it is a problem, why existing work doesn’t cut it concerning this problem, own approach and contribution, validation. And not more than that. I deviated considerably from that scheme although I had read about it, for no apparent reason.
  • For some reason, my whole introduction chapter had virtually no literature references. In a scientific work, always cite statements you don’t prove or explain.
  • I put a part of the problem description after the foundations chapter. The complete problem statement must be the very first part of the report.
  • Speaking of foundations, this chapter should have contained more of the info found in later chapters. When writing, I wanted to keep the chapters somewhat self-contained. Heiko discouraged this intention, as a thesis report is a piece of work that should be read and understood in its entirety. Having explanations of underlying techniques and frameworks in the later chapter distracted from the actual achievements of the thesis.
  • When presenting the system I implemented, I often wrote only how I designed the system, but not why. A thesis should always present design alternatives, then say which one was chosen and why.
  • In the standard limitations chapter at the end, I only listed the limitations caused by the current state of the implementation. An academic work must always address the limitations inherent to the approach. In my case, I should have explained what kind of information a static code analysis can never find out.
  • In the evaluation chapter, I presented evaluation questions (like How much time does the tool save?) and then metrics with which these questions could be answered. This is the right approach. However, I defined some metrics in terms of other, more specific questions. That’s wrong, because metrics should be clearly determinable, if possible, in terms of numbers.

And finally, my most heartfelt advice: Don’t underestimate evalutation! It’s most helpful to start really early with it. You’ll say “but I don’t have anything yet to evaluate”. Still, start at least with writing down the goals, and the metrics with which you could evaluate them. This will benefit your thesis by creating a clear direction. If you’re developing software, get the actual test data that will be used in the evaluation section of your thesis as early as possible. Then run your program on it each time you add or change something. Even in the stages when it can’t possibly work, you’ll learn something from where exactly it breaks.


  1. It’s interesting how I was randomly browsing and stumbled on this excellent post!

    Anyway, some comments based on my MSc experience..

    1. Write the Introduction chapter last – the reason for this is that this chapter really speaks about everything that will be in the thesis. It should clearly outline what the research problem is, and how the chapters will approach and solve the problem.

    2. With respect to having self-contained chapters.. I definitely agree with your supervisor.. The direction I got was that “the thesis should flow like a book”.. for example, at the end of chapter 2, introduce what will be in chapter 3 and so on.. This helps the reader/marker in reading it and displays that you know how to write.

    3. You mentioned evaluation but.. one thing I must ask especially noting some of these mistakes you mention.. Did you supervisor review your chapters (even if only briefly) before you submitted it for marking? This I found was a nice gesture made by some supervisors.

    Lastly.. I would like to highlight a point you mentioned because of its crucial importance!

    4. “A thesis should always present design alternatives, then say which one was chosen and why.” Even if the reason chosen was linked to you not being able to afford the equipment or whatever.. Highlighting WHY is critical in academic works.!

    Anyway! Good post!

    Comment by Jason Nurse — 2007-10-31 @ 11:12

  2. Thanks, Jason!

    Your comment on writing the Intro last is right. However, I found it helpful to write a rough, preliminary version at the beginning to further clarify the problem and what I actually want to do. It also helped immensely here that my advisor had me write a ten-page proposal first (which I could transform into the preliminary Intro chapter quickly).

    My advisor indeed reviewed my chapters before the final submission. Only for the evaluation chapter it didn’t quite work because the scheduling had gone a bit wrong here. Concerning the other flaws he pointed out afterwards, I’m not sure if he didn’t realize them or didn’t point them out not to make it too easy.

    Comment by thomas11 — 2007-10-31 @ 12:27

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Create a free website or blog at

%d bloggers like this: