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.

Blog at