How to Structure a Computer Science PhD Thesis: Thesis Statement, Contribution Chapters and the 60,000-Word Limit, Step by Step (2026)

A computer science PhD thesis is structured around a single claim — the thesis statement — and the two to four contributions that support it. The standard shape is an introduction that states the claim and lists the contributions, a background chapter, one contribution chapter per major result, an evaluation, related work and a conclusion that returns to the claim. The chapter count is yours; the word limit is not.

This guide follows the sequence a supervisor would use, with the expected output of each step, a worked chapter plan for a systems thesis, and the word-counting rule that catches people at submission. Regulations differ by institution — the figures below come from one department’s published rules — so check your own research degree regulations before you commit to a plan.

Why a computer science thesis is shaped differently

Three things distinguish the discipline. First, the unit of progress is the conference paper, so by the third year most candidates hold two or three peer-reviewed results that were written to stand alone and now have to be made to stand together. Second, the artefact — a system, a proof, a dataset, a prototype — is part of the contribution and has to be described, evaluated and often deposited; at Cambridge the thesis upload page lets candidates deposit a source-code package alongside the editable thesis source. Third, the field has an unusually clear idea of what a thesis is; Olin Shivers’ widely circulated advice puts it in one line: a thesis is an idea, and a dissertation is a document that supports it. Everything below follows from that.

Step 1: Write the thesis statement and the contributions list before any chapter

Expected output: one sentence and a numbered list of two to four items.

1. Write the claim as a falsifiable sentence: a learned index can replace a B-tree for read-heavy workloads without a latency penalty, or gradual typing can be made sound without a runtime cost proportional to program size. If the sentence cannot be wrong, it is a topic, not a thesis.
2. Under it, list the contributions, each one a result you can point to: a design, a proof, a system, a measurement. Each contribution will become a chapter, and each should name the paper it came from if there is one.
3. Show both to your supervisory team and keep them at the top of every draft. Examiners read the introduction, then the conclusion, then check whether the middle delivered.

Step 2: Choose the shape: systems, theory or empirical

Expected output: a chapter list with a working title for each chapter.

The discipline has three conventional shapes, and the sub-field usually decides which one you are writing.

1. Match your contributions list to a shape. A thesis with one system and three evaluations is a systems thesis with a long evaluation chapter; a thesis with three separate prototypes is three contribution chapters, each with its own evaluation section.
2. Write a working title for each chapter that names the contribution, not the activity: A log-structured index for skewed reads, not Implementation.
3. Check the count against your regulations’ word limit, not against a chapter norm. The general pattern of UK theses is set out in our piece on how many chapters a PhD thesis has; computer science sits at the shorter end.

Step 3: Build the introduction around the claim, the contributions and the publications

Expected output: a 3,000–5,000-word chapter that a non-specialist examiner can read in twenty minutes.

1. Open with the problem in two pages: what cannot currently be done, why it matters, and why the existing approaches fall short. This is the only place you argue the problem.
2. State the thesis sentence from Step 1 verbatim, then the contributions as a numbered list with a forward pointer to the chapter that delivers each one.
3. Add a publications section listing every paper, with venue and year, and stating which chapters draw on which paper and what your share of the work was for co-authored papers.
4. Close with a one-paragraph outline of the thesis. The general method for the introduction chapter applies; the computer science version is shorter and more declarative.

Step 4: Separate background from related work

Expected output: a background chapter, and a decision on where related work sits.

The two are routinely conflated and examiners notice. Background is what the reader must know to follow your contributions — the formal model, the architecture, the existing algorithm you extend — and it belongs in one chapter near the front, written for an examiner from an adjacent sub-field. Related work is the argument that your contributions are new, and it belongs wherever the contribution is: either a section at the end of each contribution chapter or a dedicated chapter before the conclusions.

1. Draft background from your papers’ preliminaries sections, then expand until an adjacent-field examiner could follow the contribution chapters without the papers.
2. Draft related work from the papers’ related-work sections, then rewrite it as a comparison organised by the dimensions on which your work differs, not as an annotated list.
3. Do not repeat the literature review of your first-year report; that was written to justify starting, this is written to justify the result.

Step 5: Turn each paper into a self-contained contribution chapter

Expected output: one chapter per contribution, 8,000–12,000 words, readable on its own.

A paper is written to be complete in twelve pages; a chapter is written to be one third of an argument. The rewrite is more than expanding the paper.

1. Unify notation, terminology and figure style across chapters. A system called one thing in chapter three and another in chapter five is the first sign the thesis was stapled together.
2. Open each chapter with a short statement of which contribution it delivers and how it depends on the previous chapter; close with a summary that hands over to the next.
3. Restore what the page limit removed: the design alternatives you rejected and why, the full experimental protocol, the negative results.
4. Give the artefact its own section: what was built, in what language, at what scale, where it is deposited, and under what licence.
5. Keep the paper’s evaluation in the chapter if it evaluates that contribution alone; move cross-contribution evaluation to Step 6. Our guide to publishing a paper from the thesis describes the reverse journey, and the two rewrites are mirror images.

Step 6: Write the evaluation the examiners will actually test

Expected output: an evaluation chapter or sections whose claims map one-to-one onto the thesis statement.

1. State the questions the evaluation answers, each traceable to a contribution or to the thesis sentence, before any result.
2. Name the baselines and say why they are the right ones; name the benchmarks, datasets and hardware exactly.
3. Report variance. For measured systems, repeated runs with the spread; for learned models, multiple seeds; for user studies, the statistical tests appropriate to the design, with effect sizes.
4. Write a threats-to-validity section — internal, external, construct — and be specific.
5. Make the results reproducible: scripts, configurations and data with the deposited artefact.

Step 7: Close with conclusions that return to the thesis statement

Expected output: a short chapter, rarely more than 3,000 words.

1. Restate the thesis sentence and say, contribution by contribution, to what extent the evidence supports it. Where it supports it partially, say so; examiners prefer a bounded claim they can accept to an unbounded one they must challenge.
2. State limitations as consequences of design decisions, not as apologies.
3. Give future work that a reader could actually start — a specific extension with a reason — rather than a list of everything you did not do.

Step 8: Count the words the way the regulations do, then cut

Expected output: a thesis inside the limit by the regulations’ own counting method.

The limits are lower than in the humanities and they are counted differently from what most candidates assume. At the University of Cambridge, the Department of Computer Science and Technology’s published rule is that a PhD thesis is not to exceed 60,000 words including tables and footnotes, but excluding appendices, bibliography, photographs and diagrams. The department is explicit that tables and equations count — its guidance is to count them as the number of words that text occupying the same area would have — and it suggests estimating the effective count from the PDF with ps2ascii thesis.pdf | wc -w. It warns that a main body of 150 pages or more has probably exceeded the limit, and its Degree Committee has resolved that candidates exceeding 175 pages will be asked to explain, while allowing applications for an extension where there is a compelling case such as an interdisciplinary thesis.

1. Find the exact wording of your own limit and what it excludes, then measure with a method that matches it, not with your word processor’s count of prose.
2. Move long proofs, full protocols and code listings to appendices where your regulations exclude them, and keep in the body only what the argument needs.
3. Cut whole results before cutting sentences. Cambridge’s guidance is blunt that a request for a larger limit is often a sign of too much work included rather than too much done: a good thesis selects from the work rather than reporting every minor result.
4. Decide the typesetting early; the LaTeX versus Word question is settled in this field by the department’s template and the examiners’ expectations, and changing tools in year three costs a month.

Worked example: a systems thesis chapter plan

The candidate holds three papers: a workshop paper describing a storage engine design, a conference paper on its concurrency control, and a second conference paper on its behaviour under skewed workloads. Thesis statement: a log-structured storage engine with epoch-based concurrency control can match the read latency of an in-memory B-tree under skewed workloads while halving write amplification.

Total body: about 55,500 words, inside a 60,000 limit with room for the tables and footnotes that the rule counts. The chapter word budgets, fixed in year two, are what stop a 90,000-word draft from happening. The field-by-field contrast is instructive: a law PhD thesis is structured around its argument and may have no methodology chapter at all, whereas the computer science thesis is structured around its evidence.

Keeping eight chapters consistent across three years

The characteristic failure in this discipline is not a missing chapter but inconsistency between chapters written a year apart: notation that drifts, a baseline that changes, a contribution claimed in the introduction and quietly narrowed in chapter five. Plan your computer science thesis in Tesify: keep the thesis statement, the contributions list, the chapter word budgets and every draft in one workspace, so that the introduction and the conclusion are written against the same claim, and use the Tesify automatic bibliography to keep the two hundred references from three papers in one consistent style at submission. The system, the proofs and the results are yours; the tool holds the structure steady while you finish them. There is a free plan; start by writing the thesis sentence and the contributions list from Step 1.

Frequently asked questions

How many chapters does a computer science PhD thesis have?

Usually six to eight: an introduction, a background chapter, two to four contribution chapters, an evaluation where the contributions are tested together, related work and a conclusion. The number follows from the contributions list, and regulations set word limits rather than chapter counts.

Can I use my published papers as thesis chapters?

Yes, and most candidates do, but the papers have to be rewritten into chapters with unified notation, restored design alternatives and full protocols, and the introduction must state which chapters draw on which papers and your share of the work. A thesis assembled from unaltered papers is a different format with its own regulations.

What is a thesis statement in a computer science PhD?

A single falsifiable sentence that the whole dissertation supports, stated in the introduction and revisited in the conclusion. The contributions are the results that support it, and each becomes a chapter.

Where does related work go in a computer science thesis?

Either at the end of each contribution chapter, which suits theses built from separate papers, or in a dedicated chapter before the conclusions, which suits a single-system thesis. Background, meaning what the reader needs to follow the work, is a separate chapter near the front in both cases.

How long is a computer science PhD thesis?

Shorter than in the humanities. The Department of Computer Science and Technology at Cambridge sets a limit of 60,000 words including tables and footnotes and excluding appendices and bibliography, and warns that a main body of 150 pages or more has probably exceeded it. Other universities set their own limits; check your regulations.

Do tables, equations and code count towards the word limit?

At Cambridge, tables and footnotes count and the department advises counting equations as the words that text of the same area would contain; appendices, bibliography, photographs and diagrams are excluded. Code listings belong in appendices or the deposited artefact. Other institutions’ rules differ.

Does the software I built have to be submitted with the thesis?

Increasingly the department expects it. Cambridge’s submission process allows a source-code package to be deposited with the thesis, and examiners in systems and machine learning routinely check that results can be reproduced from the deposited artefact.

Should the evaluation be one chapter or spread across the contribution chapters?

Both, usually. Each contribution chapter keeps the evaluation that tests it alone; a separate evaluation chapter tests the thesis statement across contributions, against named baselines and benchmarks, with variance reported and threats to validity discussed.