Thesis paper accepted

Yay, our paper on my thesis got accepted for the SE08, Software Engineering Conference Munich 2008! It’s titled Towards Automatic Construction of Reusable Prediction Models for Component-Based Performance Engineering.

Many thanks to my co-authors for making that happen!

@STRING{SE2008 = "Software Engineering 2008"}

@inproceedings{Kappler2008a,
  author = "Kappler, Thomas and Koziolek, Heiko and Krogmann, Klaus and Reussner, Ralf H.",
  editor = "Herrmann, Korbinian and Br{\"u}gge, Bernd",
  title = "Towards Automatic Construction of Reusable Prediction Models for Component-Based Performance Engineering",
  publisher = "Bonner K{\"o}llen Verlag",
  series = "LNI",
  number = "121",
  volume = "121",
  year = "2008",
  address = "Munich, Germany",
  booktitle = SE2008,
  pages = "140--154",
  month = "February" # "18--22"
}

Advertisements

Learned from writing my thesis

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.

Advice for writing a thesis

Recently, I created a detailed outline of my thesis. Looking for ideas about how to structure it best, and for stylistic advice, I went through the excellent advice collection by Tao and Yuan Xie. The following links have proven to be very helpful:

• Writing Tips is a short list of five important hints
• Common Bugs in Writing is a longer, detailed list of stylistic advice and LaTeX hints
• How to Write Up a Ph.D. Dissertation is very good advice on structuring, keeping focus, plus some typography
• How to Organize your Thesis is a great document about, well, just that.