Thesis Architecture

The outline is the architecture of your thesis. It decomposes your document into components (called chapters) with dependencies between them (called references). As for software, the architecture plays a crucial role for the success of your project.

Since text is hard to refactor (much harder than source code), it is tedious manual work to fix an outline that does not work properly later. Minimize this risk by 1) using a standard architecture and 2) early validation of a prototype (through supervisor feedback).

Standard Architecture

A suitable software architecture allows the most important operations to be performed with high performance, even if this increases the cost of other operations. A search engine architecture, for example, is optimized for performance of search queries. Other text operations, say spell checking, are slow or not supported at all.

A suitable thesis outline allows a readers to answer the most frequent questions with high performance (i.e. without having to read the whole document). Which problem does the thesis solve? Did the approach work? What are its results and limitations? Which section should I read for details? Less important questions, say in which order the ideas occured to the author, may not be answerable at all.

Since there is a set of standard questions that all thesis readers want answered, a standard architecture has emerged that all good thesis documents follow. So yours should, too:

1. Introduction
2. Terms and Definitions
3. Related Work
4. Approach
5. Evaluation
6. Future Work
7. Conclusion

Component Design

Each chapter has a well defined function in the architecture. It is not important that the chapters are called as above, but that they fulfill their respective functions.

Introduction: Describes the problem statement, illustrates why this is a problem and describes the contribution the thesis makes in solving this problem. Optionally, it can give a short description (1-3 sentences each) of the remaining chapters. Good introductions are concise, typically no longer than 4 pages.

The introduction reveals the full (but summarized) results of your work. This appears counter-intuitive: does this not break the tension, like revealing the name of the murderer on the first page of a thriller? Yes, it does. That is the whole point. A thesis, and thus its architecture, aims primarily to inform, not entertain.

Terms and Definitions: Defines the fundamental concepts your thesis builds on. Your thesis implements a new type of parser generator and uses the term non-terminal symbol a lot? Here is where you define what you mean by it. The key to this chapter is to keep it very, very short. Whenever you can, don’t reinvent a description for an established concept, but reference a text book or paper instead.

If a reader cares enough about your topic to read your thesis, he probably knows the terms anyway. The chapter thus mostly serves to disambiguate overloaded terms and as a collection of pointers to more detailed sources for novice readers.

Related Work: Collects descriptions of existing work that is related to your work. Related, in this sense, means aims to solve the same problem or uses the same approach to solve a different problem. This chapter typically reads like a structured list. Each list item summarizes a piece of work (typically a research paper) briefly and explains the relation to your work. This last part is absolutely crucial: the reader should not have to figure out the relation himself. Is your piece better from some perspective? More generalizable? More performant? Simpler? It is ok if it is not, but I want you to tell me.

One common architecture variation is to move the Related Work chapter between Evaluation and Future Work. When to use which variant depends on how well-researched the area is. If well researched, then put related work up front, since a reader first wants to know how your work differs. If it is a relatively novel area, the approach and solution should come first. If you don’t know which variant to choose, ask your supervisor.

Approach: Outlines the main thing your thesis does. Your thesis describes a novel algorith for X? Your main contribution is a case study that replicates Y? Describe it here.

Evaluation: Describes why your approach really solves the problem it claims to solve. You implemented a novel algorithm for X? This chapter describes how you ran it on a dataset and reports the results you measured. You replicated a study? This chapter gives the results and your interpretations.

The Appraoch and Evaluation chapters contain the meat of your thesis. Often, they make up half or more of the pages of the entire document.

Future Work: In science folklore, the merit of a research question is compounded by the number of interesting follow-up research questions it raises. So to show the merit of the problem you worked on, you list these questions here. If you don’t care about research folklore (I did not as a student), this chapter is still useful: whenever you stumble across something that you should do if you had unlimited time, but cannot do since you don’t, you describe it here. Typical candidates are evaluation on more study objects, investigation of potential threats to validity, … The point here is to inform the reader (and your supervisor) that you were aware of these limitatons. Limit this chapter to very few pages. Two is entirely fine, even for a Master’s thesis.

Conclusion: Short summary of the contribution and its implications. The goal is to drive home the result of your thesis. Do not repeat all the stuff you have written in other parts of the thesis in detail. Again, limit this chapter to very few pages. The shorter, the easier it is to keep consistent with the parts it summarizes.

Prototype Validation

Before you write down the document based on the architecture, get feedback on it from your supervisor.

The important point here is to get the feedback on the appropriate level of abstraction. Too little information (e.g. the chapter list above) yields too little valuable feedback. Too much text, on the other hand, risks sidetracked through discussion of details.

From my experience, the best level of abstraction is an outline that contains chapters, sections and a few bullet points for each section. This contains enough information for substantive feedback, yet is cheap enough to produce that it does not hurt too much if it turns out that parts of it have to be rewritten.

Expect several iterations on this level, until you reach an outline (down to sections and subsections) that feels good to you and has supervisor-buy-in.