Notes on Projects
There are two good ways and one bad way to do projects. The good ways are
- A theory/research project, where your main deliverable is a document (thesis) making a contribution to “the body of human knowledge” – that is you’ve either invented something new or done something better than anyone before you. For example, a machine learning project to recognise facial expressions in cats would fall into this category if (a) no-one has done this before or (b) you get higher accuracy and/or quicker running times than previous solutions. Your code can be as hacked together as you want and the interface to your programs can be terrible as long as numbers come out the other end that show you’ve done something exciting.
- An implementation project, where your main deliverable is a piece of software. You still have to write a thesis but the thesis mainly talks about your software, there’s no great new insights in the thesis. You will be marked on “does it work” and “how well does it work”, resp. “how usable is it” if you declare this as one of your goals. The quality of your implementation (does it crash on demo day?) is much more important. For example, “I want to build a 3D voxel-based landscape editor” could fall into this category. The bad way is to pick something that’s sort of half implementation and sort of half research and you’re never quite clear which of the two you’re doing, so you end up doing badly on both measures.
This section applies to projects where
- The project is implementation, not research.
- The idea comes from the student, not the supervisor.
These projects are suitable for 3rd/4th year undergraduate and conversion MSc students. If you are on one of the advanced MSc programmes, I am not the right supervisor for you - you should be doing a research project in your specialist area.
For an implementation project you need to consider
- target users (age, required computing experience, motivation for using your software etc.)
- core features (e.g. “can edit voxels”) and nice-to-have features (e.g. touchscreen support)
- milestones within the project to check how well you’re on track
- language, libraries, runtime environment etc. you’re going to use – nothing wrong with adding libraries later on but starting with e.g. Java and switching to C++ halfway through is how you end up with “half a project”
- evaluation – how can you get hold of some users in your target group to test it on – this is REALLY important when marking
As for a topic – you want to pick a field you personally find interesting, within that field something you wish it already existed (or it exists and you wish it were free and open source) or something “like X (which already exists) but for Y”. And you should have at least a rough idea of how you’d code this when you start, e.g. don’t do a machine learning project unless you’ve done (or are going to do in TB1) a machine learning unit.
From this you should be able to derive one core aim that is both strong enough that if you achieve it fully, you deserve to pass the project, and if you don’t achieve it at all then you fail the project. In other words, assuming a pass mark of 50, partially achieving the core aim should translate to a mark of 50 on the marking scale, completely achieving it should translate to a mark of 60ish and everything above that comes from particularly good implementation, write-up in your thesis and achieved optional extra features.
My criteria for accepting projects
If you want to do a project with me, you should first create a project proposal based on the topic and considerations from the last section. The core aim must be clear and there must be exactly one core aim. I will accept project proposals as PDF files with exactly one side of A4 paper; if I get many more proposals than I can supervise students then I won’t read the proposals not meeting these requirements.
The following are bad proposals:
- Too general, e.g. “I’d like to do something involving cybersecurity”.
- Too ambitious, e.g. “I’d like to use machine learning to cure cancer”.
- Too trivial, e.g. “I’d like to make tic-tac-toe game”.
- Too fuzzy, e.g. “It’ll be a bit of X and a bit of Y and some Z but none of these three are really important on their own”.
- An area that’s new to you, e.g. a cryptography project if you’re not taking at least Crypto A or have equivalent experience.
If a proposal meets these requirements, I will evaluate it on
- Is the idea feasible?
- How much help could I be for this project?
- If I get more proposals than I can supervise - how interesting is the idea?
Point 2 is my main decision criterion after I’ve sorted out the projects I don’t consider feasible. I have a background in (Java/web) software development and in security/cryptography. I will reject any projects that rely crucially on machine learning, artificial intelligence, genetic algorithms, neuroscience, computer vision, robotics etc. not because they’re bad areas – they are in fact some of the best areas for projects – but because I’m not an expert in those areas and you really want a supervisor who works in that area to do a project in it. Also we have people doing research in those areas in this department. If you’re doing computer vision and something’s not quite working, a vision expert may be able to take one look at your idea or code and say “you should try X”. As a non-expert the best I could probably come up with is “have you tried google?” which is no use.If I think I would be a suitable supervisor, I will invite you for an interview.