Guidelines for the Master or Bachelor Thesis

Günther Blaschek
also available in German
first German version: April 28, 1997
first English version: May 5, 2015
last version: September 30, 2015

These guidelines mostly refer to master theses, but they also apply to bachelor theses (except that the latter are typically shorter)

For most students, the master thesis is the first larger written work. These guidelines should provide some assistance during writing of the master thesis. They contain recommendations, rules and tips for preparation, structuring and layout. The rules described here are not "THE LAW". We nevertheless expect students to voluntarily observe the guidelines, as this increases the probability of a positive grade when the master thesis is finally approved by the supervisor.

These guidelines are meant for master students in computer science. They assume that the subject of the work is the development of software that shall be documented in the master thesis. Some master theses have a more theoretical subject or deal with literature. If that is the case, the thesis will require a different structure, which means that some of the recommendations will not be applicable.

Bachelor theses

A bachelor thesis is basically a "small master thesis". In computer science, most bachelor theses also have to do with development of some piece of software. The extent of the work is typically smaller, which means that less documentation is required. For this reason, 25 pages are usually enough for a bachelor thesis, and it should definitely not exceed 40 pages. Otherwise, the following guidelines also apply.

Purpose of a master thesis

The requirement to write a master thesis is not a chicane; the master thesis serves as

an exercise in scientific writing
the basis for the assessment by the supervisor
a user manual for the software developed in the project
documentation of the software, so that it can be maintained and extended in future projects

Preparation

Writing a master thesis requires careful planning in advance. It is strongly recommended to write the parts of the thesis in the same order in which it is supposed to be read later. This increases the probability that the thesis can be read fluently, without logical breaks and unknown terms (which are used before their definition). However, this requires that the work on the master thesis starts with a plan.

Begin with a table of contents. Constrain yourself to major (chapter) headlines and two-digit section headings (such as 2.3). Extend the table of contents with

estimated number of pages for each section
keywords about the envisioned contents

The estimation of the number of pages gives an indication of the focus of the thesis. If a major part is significantly smaller than a secondary part (such as the introduction), you may need to revise the structure. If individual chapters get too long, you should consider splitting them into multiple smaller chapters.

Select keywords such that you still remember what you meant when you eventually reach that point as you write the thesis from start to end. It is also a good idea to note a few rhetorical questions that you want to answer in the corresponding chapter. Put yourself in the shoes of the reader and try to anticipate questions he might ask. When you are done with the chapter structure, use the keywords and rhethorical questions to verify that the chapters and sections are in a logical order and that you can avoid most (if not all) forward references to subsequent chapters.

Discuss the extended table of contents with your supervisor, before you begin writing the thesis. Ask for feedback about the structure in order to reduce the risk of missing important parts.

It is highly recommended to make notes already during the project. A project diary helps you to remember the progress of the project, encountered problems and their solutions. It is also helpful to keep track of aberrations and failures. If an approach did not work out, you may still want to document it, explain why it did not work as expected, and which alternative route you eventually took. Such "lessions learned" can be more helpful for readers than a smooth story that pretends that everything worked exactly as initially planned.

Extent

The target audience of the master thesis are other computer scientists, who are familiar with the foundations of software development. Try to see your own theses through the eyes of a colleague who wants to learn more about what you have done. If you discuss the technical foundations in too much detail or length or use long-winded explanations for simple things, most readers will find your thesis boring to read. On the other hand, descriptions that are too brief leave the impression of being incomplete.

Finding a good balance between brevity and exhaustiveness is not easy. The best representation depends on the difficulty of the topic. As a general guideline, you should strive to fit the contents of the thesis within about 80 pages. To enforce a brief and compact style, we limit the extent to at most 100 pages. Instead of trying to fill as many pages as possible, rather try to cover the relevant aspects in as few pages as possible. In particular, do not stretch your thesis by adding empty talk, oversized screenshots, pages of source code, or long explanations of all the variables in your code. Always remember that your master thesis will be assessed by its contents, not by its length.

If you are in doubt, consider whether you would like to read all the details of a lengthy explanation. Would you really want to study all the technical details, or would you rather skip a section that is too elaborate?

Your master thesis should contain everything that is necessary to understand your work. It should be complete, but you can expect basic knowledge from the reader. The complete source code does not belong in the master thesis. If necessary (discuss this with your supervisor), you should submit the source text separately on CD or DVD, or deliver a printed copy of the source text as an extra document.

Try to describe the subject of your thesis from multiple perspectives. In particular, you should cover the following aspects:

Task.: What was the original assignment? In which discipline of computer science does it belong? Does your implementation fulfill all requirements? Did you exceed them in some aspects, or did you need to make restrictions?
Overview.: Describe the essential parts of the software. What is its purpose, what are the most important properties or benefits? What does the software do, what was explicitly excluded?
Usage.: Show the software from the perspective of a user. User concrete examples to show how it can be used to solve real-world problems, but avoid lengthy explanations of menu commands or other details of the actual usage.
Results.: Use a few simple examples to illustrate the results produced by the software.
Comparison with other software.: Are there other programs that already perform simular functions? What are the essential differences between your work and other solutions? What are the new contributions of your work?
Concepts.: Describe the foundations and technical concepts on which your implementation rests. Show the architecture of the software and illustrate the functional building blocks and the data flow. In the case of object-oriented solutions, you should also give an overview of the class hierarchy and show how objects interact at runtime.
Interfaces.: Describe how your software interacts with the outside world; show how it cooperates with other programs, for example, how results from your work can be used in other software components.
Implementation.: You do not need to describe the entire implementation. Select a few interesting problems and show how you solved them. Make sure to show the details in their context; explain the role of an implementation detail within the whole system, so that the readers can see the big picture.
Extension instructions.: Explain in which ways and how your software can be extended and describe how extensions and future improvements can be made. Use a small concrete example to demonstrate an actual extension.
Technical data.: List some representative measurements that illustrate the extent and performance of your software. Examples for such measurements are lines of code, run times and memory consumption. Represent the data graphically. Help the reader to understand the numbers by giving an interpretation: Explain differences and outliers, point at especially good or bad results, and show the limits of your software.
Critical review.: Try to review your own work objectively. Which parts are you particularly proud of, what could be improved, what would you make differently if you were to do the same task again with the knowledge that you have now? Which tools did you use during your work, were they helpful for your tasks?

The order of the items in the above enumeration has proven useful, but you do not need to slavishly follow this arrangement.

When you describe your own work, it helps when you are proud of your achievements. Plain technical descriptions are often boring to read. if you are enthusiastic about your solution and the results, you will write in a lively style that makes your thesis a pleasure to read. Try to involve the reader with rhethorical questions. Explain problems and show which ideas lead to your solution.

Structure

When you plan the chapter structure of your thesis, it is recommended that you proceed in a top-down fashion. Think about what you want to say in which chapter, then successively decompose the contents, similar to stepwise refinement.

You can use the following basic scheme for structuring your thesis:

Introduction.: Assignment, results, overview of the thesis (short description of the remaining chapters).
Foundations.: Theoretical and technical background of the thesis; contact points with other disciplines.
Usage.: Thought model of the user interface, typical use cases and workflow, produced results.
Architecture.: Coarse structure in functional blocks, hierarchies, data flow, interfaces.
Implementation.: Technical description of the solution, data structures, interesting algorithms.
Technical data.: Program size, execution times, memory requirements.
Review.: Critical self-assessment of your own work.
Literature.
Appendixes.

The recommended structure shown here does not necessarily need to correspond to the chapters. It could, for example, be reasonable to spend more than one chapter on the implementation or to combine technical data and review into a single chapter. In some cases, it may also be a good idea to swap the order of chapters, for example when the implementation concepts of a class library are necessary to understand how it can be used.

Make sure to handle the basics first, so that subsequent chapters can refer to them.

Avoid too deeply nested chapters and sections. Three levels (1.2.3) are usually sufficient.

Tiny sections with just a few lines do not justify a separate section heading. If that happens, do not artificially blow up the contents, but rather revise the section structure.

You should also create a logical structure within sections. For example, paragraphs, indentations and sub-headings without numbers can improve readability. At any rate, split long paragraphs into shorter ones at logical "break points".

Literature and appendixes do not have chapter numbers. Whether or not appendixes are a good idea depends on the subject of your thesis. You can insert short pieces of source code (less than a single page) directly in the relevant chapters; longer program fragments (which would disturb the flow of reading, but are not absolutely necessary for understanding a chapter) can be banished into an appendix. This is, by the way, one of the rare cases where a forward reference is acceptable.

Style

The description of the best program will be awkward to read if the reader is distracted by bad style. Unfortunately, good writing style cannot be learned in the fast track; it requires experience and practice. In school, we typically learn writing stories and essays, but not technical writing. The following points give a few hints that might help during writing a master thesis.

Use simple, objective and clear language. Avoid pompous and exaggerated terms, "impressive" foreign words, long and nested sentences that must be read twice to understand the syntactic structure.
Word repetitions are frowned upon in narratives, but essential for understanding technical descriptions. If you use the terms "input window", "active window", "front window", "current window" and "focus window" side by side, the reader will assume that you had a good reason to use multiple terms. He will likely try to figure out the subtle differences. You should therefore consequently use the same term for the same meaning. Even better: Explicitly define the term when you first use it.
Avoid jargon, even if you think that it's "in" and makes your thesis appear "cool". Use established terms that already have well-defined meanings in the computer science community.
Be careful with abbreviations. Don't expect that all your readers know what ADSP, TCL, LLC and PST mean. Use the long form instead. Abbreviations are acceptable only when they are well-established (such as TCP and FTP) or their long form would be too clumsy. If you still decide to use an abbreviation to save space, make sure that you at least define the meaning of the abbreviation upon its first occurrence.
The first person form (I, me, my) is generally regarded as bad style in technical publications. Use impersonal phrases and describe the final state of a development instead of telling what you did. Instead of "I had to split the program into two layers", write that "The program consists of two layers". The first person form is acceptable only at the and of the thesis where you write about your personal experience.
Avoid filler words. When you search the text for words like "very", "actually", "basically", "relatively", "rather", "quite", "in principle", you will very easily find that these relatively frequent words can actually be omitted quite often in principle, because they basically are rather meaningless. By omitting superfluous words, your text becomes more precise.

Layout and typography

The visual appearance of the master thesis gives a first impression of the quality. A thesis with a clean and aesthetic layout is pleasant to read. The following enumeration gives a few hints for adequate formatting.

Use a serif font for the body text, such as Times. Use a font size of 12 with a line spacing between 14 and 16 points.
For headings, you can use a plain sans-serif font, such as Helvetica. Recommended font sizes for headings are 14 to 24 points. The spacing between the heading and the following text (which is labeled by the heading) should be smaller than the spacing above the heading.
Avoid successive headings. Start every chapter and section with a short introduction or transition from the previous text.
Source text is often printed in a monospaced font. However, many such fonts (such as Courier) have a thinner appearance than the body text, which results in an uneven layout. To avoid this effect, consider using a proportional font, like Helvetica. This has the additional advantage that more text fits in a line because of the tighter tracking.
Variable names and other short source code fragments within body text should be indicated with a different font. Some authors use italics (e.g. myVariable) for this purpose, whereas others prefer the same font that is used for larger program fragments. (e.g. myVariable). When you mix fonts within a paragraph, adjust the font sizes such that pieces in different fonts appear with the same cap height. For example, Helvetica 11 looks good within body text in Times 12.
Emphasis should be added in italics. Do not use underlining; this is a relic from the typewriter age that results in struck through descenders.
Boldface has an obtrusive effect. Use this style only where you deliberately want to achieve this effect, for example for the introduction of new terms.
Avoid text in ALL CAPS, as it produces an uneasy appearance.
Every page should have a header and/or footer, which contains at least the name of the current chapter and the page number.
Leave enough space at the left and right borders of each page. Consider that binding consumes some of the space. Adding more space makes the final thesis easier to read in the printed form.
Footnotes are often used in other disciplines, such as in law, economics and social sciences, but not in most technical disciplines, such as computer science. Important explanations should be included in the body text and not in a footnote, where they can be easily overlooked. Unimportant explanations can be omitted altogether.
Use simple and clean illustrations. Avoid ornaments and meaningless decorations that distract from the hard facts. Use sans-serif fonts to label parts of the illustrations.
Avoid grayscale and colors in pictures. Many photocopiers and printers still cannot reliably reproduce colors and subtle nuances in shades. Instead, find other ways to emphasize important parts in illustrations (such as frames or thick lines). When you include screenshots, take care of elements that may get lost in reproductions. If you are not sure, try photocopying a sample page.
Number your pictures and add captions and legends to pictures. Make sure that the text before or after a picture refers to the picture and explains in more detail what the picture is supposed to illustrate.
References to literature are usually written in brackets [Blaschek 1994]. They should name the primary author and the publication year. The literature list at the end of the thesis should be systematically structured. Each entry should at least contain the names of the authors, title of the publication, publisher and year of publication.

Organizational aspects

Master theses need to comply to certain formal criteria. Since these rules are subject to change, they are not explicitly listed here. Please contact the Department of Examination and Recognition Services for up-to-date information (see here for general guidelines; to read the English version, click the "EN" link in the top right). The rules for the overall form of master theses can be found here (in German).

As soon as you have finished the table of contents, show it to your supervisor.

When you have finished your thesis, check it for typical errors:

Use a spell checker to find spelling errors.
Read your own thesis from start to end, as if you had never seen it before. Fix "the last mistakes", then ask a colleague to read your thesis and check for issues that you may have missed due to routine blindness.
If English is not your native language, try to find a native speaker and ask him or her to check for mistakes.

When you are convinced that you have done everything for a good master thesis, hand a "preliminary final version" over to your supervisor, who will then check your thesis once for completeness, structure and style. It is then up to you to incorporate the feedback into your thesis.

Please consult the Department of Examination and Recognition Services and ask about the official deadlines and time limits. Your supervisor may need about two weeks to check the preliminary version, and you will need to allocate sufficient time for the final touches, copying and binding.