How to Write a Computer Science Dissertation Step by Step (2026)

A computer science dissertation lives or dies on reproducibility: an examiner or reviewer needs to be able to look at your codebase, rerun your experiment, and get results that match your reported numbers. Learning how to write a computer science dissertation means treating your code and your write-up as two halves of a single deliverable — version-controlled, benchmarked, and documented well enough that someone else could pick it up.

This guide walks through eight steps for a typical systems, applied AI, or software engineering dissertation — from scoping your research problem to formatting your final submission in LaTeX with IEEE or ACM-style citations.

Step 1: Scope Your Research Problem

The most common failure mode in computer science dissertations is scope that’s too broad for the timeline. Narrow your problem to something you can implement and evaluate within your available months: not “improve recommendation systems” but “evaluate whether a specific graph-based reranking method improves cold-start recommendation accuracy on a defined dataset.” A supervisor can help calibrate scope, but the sharper you make the question yourself, the faster that conversation goes.

Decide early whether your dissertation is systems-focused (building and benchmarking a working implementation) or theory-focused (proofs, formal models, algorithmic analysis) — this decision shapes almost every step that follows, including your evaluation methodology and expected results format. Many students try to do both and end up with neither a solid system nor a rigorous proof; pick one primary mode and treat the other as a supporting element at most.

Step 2: Survey Related Work

Search venues appropriate to your subfield (ACM Digital Library, IEEE Xplore, arXiv, and top-tier conference proceedings like NeurIPS, SIGMOD, or OSDI depending on your area) rather than relying only on general academic databases. Your related work section needs to do more than summarise — it should position your contribution against the two or three closest existing approaches and explain specifically what’s different about yours: a new technique, a new evaluation setting, or a combination not previously tested together.

Step 3: Design Your System or Experiment

Before writing a line of code, sketch your system architecture or experimental design on paper: what are the inputs, outputs, and evaluation metrics? If you’re building a system, define your baselines now — what will you compare against? If you’re running an experiment, define your independent and dependent variables and your success criteria before you start collecting data, not after you see results that happen to look good. Write this design down in a short internal document even if your department doesn’t require it formally — it becomes the skeleton of your methodology chapter later.

Step 4: Implement With Version Control

Use Git from day one, with meaningful commit messages and a branch structure that separates experimental features from your stable baseline. This isn’t just good practice — it’s increasingly an explicit requirement. Reproducibility standards adopted by conferences like SIGMOD and PLDI expect a tagged release matching the exact code version used to generate your reported results, and a development repository alone (without version tags) is generally not considered a valid reproducibility artifact. Our guide on how to back up your thesis with version control covers Git workflows specifically for long-running academic projects, including how to handle large datasets that shouldn’t live directly in your repository.

Step 5: Run Experiments and Collect Results

Run your experiments enough times to report meaningful statistics — a single run of a stochastic algorithm tells you very little. Log everything: random seeds, hyperparameters, hardware specs, and exact dataset versions, since any of these can affect reproducibility. If you’re comparing against baselines, run them under identical conditions to your own method rather than citing baseline numbers from the original paper, which may have used different hardware or preprocessing. Automate your experiment pipeline where possible with a script rather than manual steps, so re-running everything before submission takes minutes, not days.

Step 6: Write the Results and Evaluation Chapter

Keep description and interpretation separate. State your evaluation questions first, describe your experimental setup and baselines, then present results — tables, plots, statistical significance where relevant — without yet explaining what they mean. Save interpretation for a following section or your discussion chapter. Our detailed guide on how to write a thesis results chapter covers this description-versus-interpretation split in more depth, with examples from empirical studies.

Step 7: Discuss Limitations and Future Work

Examiners expect an honest limitations section, not a defensive one. If your evaluation only covered one dataset, one hardware configuration, or one problem domain, say so explicitly and explain what would need to change to generalise your findings. A well-written limitations section signals scientific maturity and is not a mark against your dissertation — vague or missing limitations sections are what actually cost marks.

Step 8: Format and Submit

Most computer science departments provide an official LaTeX thesis template, typically hosted and edited collaboratively on Overleaf — check with your department before building your own template from scratch. Citation style is almost always IEEE or ACM (numbered, not author-date), though some theory-heavy programmes still expect APA or Harvard, so confirm with your supervisor. Our guide on how to collaborate on Overleaf covers shared editing, version history, and template setup if you’re working with co-authors or a supervisor who reviews chapters directly in the document.

Common Pitfalls That Delay Submission

• Scope creep mid-project. Adding “one more experiment” or “one more baseline” three weeks before submission is the single most common reason CS dissertations run late. Freeze your evaluation plan once you’ve started data collection.
• No tagged release. A messy, uncommitted working directory at submission time makes it impossible for an examiner to verify your results. Tag a clean release the moment your final experiments are complete, before you start writing up.
• Baseline comparisons that aren’t apples-to-apples. Citing a baseline’s reported numbers from its original paper, rather than re-running it under your own conditions, is a common source of examiner pushback since hardware and preprocessing differences can produce misleading comparisons.
• Underestimating the write-up. Students who spend months on implementation sometimes leave only a week to write the dissertation itself. Start drafting your related work and methodology chapters early, in parallel with implementation, rather than after everything is built.

For a broader view of how computer science dissertations compare structurally to other disciplines, see our annotated dissertation examples across six disciplines, which includes a computer science sample chapter breakdown. And if your department requires IEEE-numbered citations specifically, Tesify Pro’s IEEE referencing style guide covers the exact numbering and reference-list format expected.

FAQ