Department of Computer Science and Technology

The Project

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 Overseers. 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. The first few weeks of your project will often involve you in 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. 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 overseers 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 overseers.

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 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.