skip to content

Department of Computer Science and Technology


In formal terms work on your project can begin only when the Laboratory has accepted your proposal. In practice waiting to see the official note to this effect is unnecessary and you should start as soon as informal agreement has been reached with your Project Checkers. If you have a clear idea of what project you want to do and are confident that it will prove acceptable you can start even earlier, but remember that anything done that early should be reported in your project proposal.

Early days

Your project as a whole will be a large piece of work, normally much larger than any piece of programming you have been responsible for before. It is therefore inadvisable to jump straight into the middle of coding at the very start. If you will be working in a programming language that will be new to you then you should practise and learn it by writing small-scale code fragments (perhaps related to the code you will eventually want). If you will be using some specialist hardware (say a graphics display) or some large library or package you will need to show that you are in control by preparing demonstrations of your ability to drive it. Do not rush headlong into the production of large bodies of monolithic code. Take the time to prepare properly, usually through a substantial amount of reading: studying manuals, searching libraries for copies of research papers or technical reports and checking the details of algorithms in textbooks. The larger a piece of work is the more important it becomes to have a clear plan as to how it will be executed, so you should probably try to add more detail to the work-plan prepared for your proposal.

Moving on

It will help both you and your Supervisor if, early in the project year, you can generate a steady stream of small-scale but visible achievements so that both of you can see clearly that work is underway and progress is being achieved. It is necessary to keep project work moving all the time despite the conflicting demands of lectures and supervision work, since it is easy to let days of inaction stretch into weeks. Furthermore it is remarkably easy to forget what was going on even in your own programs, and more than a couple of days’ break in work can disrupt the flow of your ideas. By the end of the year it is expected that candidates will be self-reliant and in almost full command of their programs, but at the start this will generally not be so. When you find yourself in difficulty, and having made some reasonable effort to resolve things for yourself, you should seek assistance promptly — in many cases your Supervisor will be able to resolve your difficulties quickly and painlessly. As you work you should be testing both your ideas and your code all the time. This is easiest if your entire design has a clear modular structure. You should be prepared to write temporary bodies of code by way of scaffolding to support components that you want to test. If you put extra print statements into your programs so that you can trace their behaviour you should aim for an ideal whereby your trace output is in the form in which you would present a worked example of your algorithm; it should be sufficiently detailed to show all important internal working, but concise enough to be readable. Trace output consisting of tens or hundreds of pages of numbers amounts to an admission of defeat.

Your project plan will have given you some idea about the eventual size of your programs. It is almost certain that you will need to keep the final version of your code in the form of a set of files which get separately compiled and then linked together. Although some of your early experiments may be conducted using a compile-load-and-go mode of work, it will probably be useful to organise yourself for module-by-module recompilation fairly early. On Unix systems you will probably rely on the make utility or similar software. Whatever machine you are using you should find out how to arrange that large recompilations or potentially lengthy test runs are executed with low priority or at off-peak periods.

Evaluation methods

Your project report must describe how the project has been evaluated, and your Project Checkers are likely to discuss your plans for evaluation. Evaluation involves collecting evidence that tests or demonstrates how far the project has met its objectives. Different kinds of evidence are appropriate to different types of project, and you should discuss this with your Supervisor and Project Checkers.

Collecting, analysing and presenting evidence for the evaluation of your project requires specific activities, and time for these should be allowed in your project plan. Evaluation methods should be selected according to the objectives of the project, for example:

  • Objectives involving engineering performance: experiments to collect quantitative data comparing a baseline to your work, as well as other (existing) solutions.
  • Objectives involving proof of correctness: mathematical proof will be involved.
  • Objectives involving functional performance: systematic and reproducible testing procedures will be involved.
  • Objectives involving user productivity: measures of task performance will be involved.
  • Objectives involving aesthetic or affective outcomes: qualitative judgment data will be involved.

Evaluation methods are discussed in various parts of the Tripos curriculum. Philosophy of evaluation, including comparison of these different approaches, is explicitly taught in HCI and Software Engineering courses. Other courses address specific techniques, but the project will require you to compare and select from the available methods you have been taught, as appropriate to the project objectives and the advice of your Supervisor.

Keeping notes

When a project is complete it can often be hard to look back and remember what aspects of it had seemed particularly uncertain at the start, and to trace all the problems that were overcome on the way to the successful completion. A project log-book can provide a great deal of help here. It can be a diary that will let you keep track of where time has gone, a place to make notes on examples you want to include in your dissertation and a reminder of why certain design decisions were made. Such a log can obviously prove its worth at the end of the year when the dissertation is being written, but it can be equally important earlier by giving you a clear view about the rate at which you have been able to make progress, and hence an indication as to how you should plan for the future. In keeping such a log it is useful to record failures, frustrations and dead ends as well as successes, since you may well wish to cite some of these to support the choices that you make.

Overall, as you start work you need to keep in view the final objective, which is the preparation of a dissertation in which you submit clear evidence that you carried out a significant piece of work in a coherent and well organised manner, making proper use of known results and demonstrating your ability to plan and complete such work within a predefined time scale.

Backing up files

When working with several thousand lines of code over a period of months it becomes important to consider file backup and recoverability, and you should organise your work so that the inevitable mistakes can easily be undone.

Modern computer systems are remarkably reliable. Those administered by the University or Department (e.g. the MCS) will have their file systems carefully and regularly backed up as protection against any hardware failure.

The Department observes that maybe one or two of its students suffer a serious computer failure each year. So while this is not very likely to hit you, you need to be protected in case it does. You should institute a regular schedule for backing up project files, probably using all of USB memory sticks, the MCS and cloud services..

In practice the biggest danger to your files is not hardware failure but clumsy editing or confusion about file-names; when tired it is painfully easy to delete an important file instead of the temporary one you intended to discard. There are also times when you may discover that a full week’s work of heavy adjustment to your code was in fact misguided and that the best thing to do would be to restore your files to an earlier state. You should therefore arrange to make regular safe copies of your files, and preserve several generations of them. Using revision control, such as Git or Subversion is strongly recommended. The situation when this becomes most critical is when you are working under most pressure, which is of course when making backups feels most like a piece of bureaucracy that wastes your time!

Intellectual property

In general, students in Cambridge own all intellectual property they create, and this extends to the project and dissertation. Further information can be found in the Chapter on Intellectual Property in Statutes and Ordinances

A small number of students, however, sign away some or all of their Intellectual Property Rights (IPR), either as a condition of a sponsorship agreement or as a condition of working on a project with externally-funded colleagues. We strongly recommend students who are asked to assign IPR to discuss this with their Director of Studies before signing any formal paperwork. All materials submitted for examination must be free from third-party IP restrictions or other disclosure restrictions (e.g. such as those arising from NDA or patent applications).

The source code for the project that is created or substantially modified must be submitted along with the dissertation itself. However, libraries or other bodies of code that would be required to make the project run do not need to be submitted and could be subject to NDA.

No publication or exploitation rights are conveyed to the University by submission.  Provided IPR has not been assigned to other parties, students are welcome, and even encouraged, to exploit their work commercially. However, some points are worth noting:

  • Material being submitted for a UK patent requires absence of prior public disclosure. If you plan to patent something then either omit it from your dissertation or file the patent first. Even the act of examining (consider e.g. plagiarism-detection software) may represent a form of disclosure. Examiners will not sign NDAs. In general, it is unwise to divert energy from your project into patents; if you do come up with valuable software your primary IP protection is likely to be your copyright in it. If you are concerned, discuss the situation with your Director of Studies.
  • Copyright arises automatically in both text and code that you write, and in images and video you take. You do not have to do anything for this to happen, but adding a copyright notice to work you want to protect can help resolve disputes later.
  • A University project and a commercial product are valued according to very different metrics. Spend your time working to get a good final project mark, and only then worry about the possibility of making money.

Changes to the Original Plan

Once you have started on a project it is expected that you will follow through the plan as laid out in your proposal. Small adjustments to the emphasis that you put on different aspects of the work and refinements to the plan made as you go are of course always acceptable. However, in a very few cases, candidates want or need to make larger changes, and this section discusses that possibility. There are two classes of circumstance that might force you to have to abandon a project part way through and re-design it from the start or seek another. The first would be if (despite proper checking earlier on) some vital piece of hardware, software or data suddenly became unavailable and no alternative could be found. Cases of this sort should be very rare given the processes involved in getting the Project Resource Form signed, but natural or man-made disasters (lightning strikes, fires, floods, ...) do sometimes occur, and it is not always possible to recover from them rapidly enough to allow a one-year project to proceed undisturbed. The second case arises when a candidate finds that work is progressing much more slowly than originally predicted and that it is unrealistic to expect that the targets originally set will be attained.

In both of these cases there are three steps involved in getting the project back under control:

  1. Identify as promptly as possible that there is a problem which could potentially grow into a serious one. Get in touch with your Supervisor and discuss the issue, trying to see whether there is an easy way to side-step the problem. A regular review of milestones will let you spot work-rate problems.
  2. Try to get the difficulty resolved, setting a fixed date and a clearly stated way of knowing whether your problems are over. For example, “If the extra hardware is delivered by next Friday I will be able to catch up”.
  3. If step 2 does not correct your problems, seek further help from your Director of Studies as well as your Supervisor and, if your project will have to end up being significantly different from that described in your project proposal, get in touch with your Project Checkers or the Briefing Officer.

It should be obvious that problems are much easier to resolve if found early, and if discussed with your various advisers. Large changes of direction in a project are very strongly discouraged, and you should expect Supervisors, Directors of Studies and the Project Checkers to suggest ways of getting approximations to the original work done. These may include simulating unavailable equipment, concentrating more on a secure (if perhaps unexciting) aspect of a project or re-arranging your affairs by giving up other activities to make more time available for project work.