You can start working on your project as soon as you, your Supervisor(s), and your DoS are happy with your project proposal and you have submitted it. If you have a clear idea of what project you want to do and you are confident that it will prove acceptable you can start earlier, but remember that anything done before the proposal submission must be reported in the starting point section of 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, reading 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.
Making progress with the implementation
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 Day-to-Day 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, and you write unit tests for every significant module so that you can rerun the tests frequently. You should be prepared to write temporary scaffolding code support components that you want to test.
Evaluation methods
Your project proposal must describe your success criteria and evaluation plan, and your dissertation must report how the project has been evaluated. 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 your evaluation plans with your Supervisors.
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 your work to a baseline, 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 you overcame 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 your time has gone, a place to make notes on examples you want to include in your dissertation, and a reminder of why you made certain design decisions. Such a log can obviously prove its worth at the end of the year when you are writing the dissertation, 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 engineering techniques, 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. You have to ensure that if you delete the wrong data by mistake, you can quickly recover without losing any work. 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. Using a revision control system such as Git or Subversion is therefore strongly recommended.
You also need to consider the risk that your computer fails suddenly or is stolen. You should therefore arrange to make regular safe copies of your files to another system. For example, if using Git you can push your repository to the University GitLab service or to GitHub, and you can make regular backups to an external hard drive. The situation when this becomes most critical is when you are working under the 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 the 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.
- If you agree to it, your dissertation will be made available to students and staff of the University on the Department’s website. See the section about the Declaration of Originality for details.
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 as you go are 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 circumstances that might force you 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 thought you have put into your project proposal, but disasters (lightning strikes, fires, floods, ...) do sometimes occur, and it is not always possible to recover from them rapidly enough to allow a seven-month project to proceed undisturbed. The second case arises when you find that work is progressing much more slowly than originally predicted, that it is unrealistic to expect that the targets originally set will be attained, and that a scaled-down project with reduced scope is not possible.
In both of these cases there are three steps involved in getting the project back under control:
- Identify as promptly as possible that there is a problem which could potentially grow into a serious one. Get in touch with both your Day-to-Day Supervisor and your Marking 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.
- 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”.
- If step 2 does not correct your problems, seek further help from your Director of Studies as well as your Supervisors, and develop a new project plan that both your Supervisors and your DoS agree with.
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 and Directors of Studies 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.
