Browse Brian’s Bookshelf

It’s not a project yet

Despite everything being named ‘project’ during the project selection process, that’s actually the wrong name. You aren't looking at a list of projects but a list of topics. You sign up to a topic, then you work with the supervisor to find your project within that topic.

Think of it as deciding to go on holiday. If you’re just ‘going on holiday’ then you can feel overwhelmed by the choices. Once you've decided on a type of holiday or a place to visit, then you can start identifying requirements and plan accordingly. It’s now going from a holiday plan to becoming your holiday. It’s the same going from topic to project. Once you have your topic, you work with your supervisor to decide an initial plan. That initial plan will ‘go wrong’ so you adjust as you go. That’s all part of the fun.

It’s up to you

Many of the questions students have about potential projects and even the project they are doing can be answered ‘it’s up to you — providing you justify your choices.’ A higher quality project will, for each key choice, rule a winner in and other contenders out. Not justifying your choices leaves you open to easy criticism why you did Y instead of X, and questions whether you thought it through properly or even at all. Do ensure your project has breadth (covers multiple things) and depth (some things in more detail).

• ‘How much of an interface / system / game to write?’
  It’s up to you — providing you justify your choices.
• ‘Should I concentrate on this or that?’
  It’s up to you — providing you justify your choices.
• ‘How many cases / scenarios to cover?’
  It’s up to you — providing you justify your choices.
• ‘What language / libraries / framework / storage / data / guidelines should I use?’
  It’s up to you — providing you justify your choices.
• ‘May I…?’
  It’s up to you — providing you justify your choices.

Limitations

As you turn the topic into your project you will define the project’s limitations: what you think you will (not) attempt. Time constraints govern many aspects. As the project runs, you will likely add and modify limitations, especially as tasks prove harder or take longer. You don’t have time to fight every battle, let alone win them all, so don’t try — but don’t give up at the first sign of trouble. Project limitations are actually a benefit: constraints require creativity and creativity shows thinking.

A ‘Project Limitations’ report section is where you outline and justify the battles fought (perhaps with comment whether you now think you made the right choices). This is your chance to set the narrative: like setting your own exam questions. This sets the readers’ (and markers’) expectations. This matters because you don’t want to risk others feeling unsatisfied or even dissatisfied with your work: the same feeling you’ve experienced with films, books, or games but for actual degree marks — yours.

Me as your supervisor:

While considering my projects, also consider whether you will like working with me. Some students believe I’m the dream supervisor 😇, others know I’m a nightmare 👹. Think carefully about both what you want and what you need from a supervisor. Consider me sympathetic and structured, but demanding.

You can expect (many) (usually long) emails. I like writing. I also like being interested in your project — expect (long) emails about this. I like attention to detail — expect (long) emails about this too. I was raised ‘if it’s worth doing, it’s worth doing properly’ so I am always seeking ways to make improvements. I will make more suggestions for enhancements to your project than you can fit in the time available because that is what my project supervisors did to me — and I am all the better for it. It is up to you to manage what and how much to do.

I expect regular communication and for you to have a basic end-to-end working version of your program / system within the first quarter of the project time. I expect you to do a user study.

Fictitious yet somehow entirely plausible quotes from imaginary former students:

He taught me an engaging writing style. Paige Turner He gave me plenty of momentum throughout my project. Stan Still He helped us overcome obstacles and produce a project that opened doors. Barb Dwyer & Dawn Hobbs As an NLP expert, he knows a lot about trees. Tim Burr He does have a sense of humour but he wasn't kidding about the emails. Jo King

You as my project student:

You genuinely need to enjoy reading emails and feel comfortable writing (weekly) short diaries with honest updates including problems and mistakes. I expect you to use plain text for information and version control for everything. Text file manipulation skills, especially from the command-line, are always handy. You need to (learn to) use appropriate tools properly especially a proper editor or IDE (preferably from JetBrains). You must also look constantly for improvements, expansions, and increased usability.

Early on you need a reasonable idea how you will define and evaluate ‘success’ in your project. Ideally you should use an end-to-end approach instead of top-down or bottom-up. You need contingencies for when things go better (or worse) than expected and you find yourself expanding (or shrinking) your goals.

There’s no need to be shy about gaps in your knowledge or be embarrassed about any modules you’ve struggled with: this is all about learning and improving. I don’t care what grades you’ve scored. I am more impressed by grade averages that have improved than those that have been consistently good. It’s less about how good you were or are now, and more about how much better you can be.

Expectations

As a minimum, I expect my project students to do or attempt:

1. Use engineering requirements.
2. Use version control, ideally on the University’s server.
3. Use project management tools or techniques.
4. Have proper testing, eg regression testing.
5. Test for statistically significant results.
6. Find and follow excellent guidelines for designing interfaces, like these from the Nielsen-Norman group.
7. Have suitable contrast in any GUI for users with low-vision.
8. Make the interface suitable for users with colour vision deficiency (colour blindness).
9. Estimate the carbon footprint of your end product.
10. Build using an end-to-end approach and make a minimal working example (MWE) as soon as possible.
11. Design one or more overview diagrams of the project as soon as possible.
12. Conduct a usability study (if appropriate).
13. Have fun and show off a little.
14. Click here Hide an Easter Egg in your project.

Two typical errors

Two of the costliest mistakes students make with projects are spending (far) too much time writing code yet (far) too little time writing the report, or rather too little time rewriting the report because that’s where you upgrade the quality. You should assume that only the parts of your practical work described clearly in your report will gain marks.

A typical major mistake with the report is not telling us what you have done — it is hard for examiners to give marks to something they don’t know you’ve done. Another mistake is telling us what you have done but not what you have learnt. It doesn’t matter that parts of your project did not work: what really matters is showing what you’ve learnt from those problems.¹ Mistakes make the best teachers.

¹ Note that I am ‘allergic’ to the term ‘issue(s)’ in this context so please call a problem ‘a problem.’

Justify your decisions…

It is all too easy to criticise a project when the key decisions are not justified. If you don’t justify your decisions, any reader or examiner who disagrees with your choice(s) might think you are wrong or lazy. Thus every project should include a section with:

• lists of criteria: one list per important "thing" such as programming language, framework or game engine, data sets, algorithms, design guidelines;
• a set of candidates per "thing'"
• an evaluation of each candidate against the appropriate criteria;
• a "winner" for each "thing."

… and pick a winner

When evaluating candidates sometimes there is one clear winner. There can be multiple candidates which meet all criteria:

• so first consider if the criteria are strict enough;
• or pick a winner using a new criterion (eg I know this language; I want to learn this language; this framework has lots of help; I found a similar program / game / system / game and wanted to follow while changing the emphasis from one thing to another thing...

Sometimes there is no one candidate that meets all the criteria, so you choose the "best" (define "best"), or choose two or more that you will somehow use separately or in combination. This is really common with data sets or assets for games.

More advice

I urge you to write the user guide before you code your interface; then code the interface to match the instructions. This greatly increases the usability of the final software.

Another trap is trying to solve every problem you encounter, so stick to the project’s main aims. While you will meet problems head-on and defeat them, be prepared to circumvent or simplify some problems. You might even need to adjust the project’s goals.

Do your best to have lots of small goals with short deadlines. Build a contingency of about two weeks into your timetable to allow for unexpected yet entirely predictable problems: distractions, anxiety, tiredness, and illness. Never forget: ‘simple’ software simply never is, tools rarely integrate smoothly, and there’s always one more bug.

Document design

Turn your presentations into PDFs so you can be more confident that they will display as you intend on another computer. Use more graphics and less text in your slides. Read and follow document design advice from Edward Tufte, Robert Bringhurst, and Michael Alley.

Choose professionally designed fonts that were intended for the exact purpose you want. Check professionally written reviews of fonts by other font designers. If you don’t believe that is important then read the short story by Mark Twain How I Edited an Agricultural Paper Once — it will help if you have a basic knowledge of agriculture and farming.

Learn about colour theory to enhance your designs. Use websites, like those by paint manufacturers, to help create colour-matched designs. Check your results on WebAIM and colour-blindness simulators.

Be safe

Ensure you make multiple regular backups and keep them physically separate in case of flood, fire, or theft. Be careful about putting your work on public-facing websites: assume cloud storage is public. Remember your work isn’t stored on a cloud: it’s stored on someone’s server.

If you are intending to use your own computer for a computationally intensive project or running a virtual machine, it’s worth replacing the thermal paste on the CPU and GPU. Clean or replace cooling fans, and consider a laptop cooler. I have had 3 previous project students whose own laptops were damaged or destroyed by overheating running experiments that took days or even weeks to complete. Try free software to monitor computer temperatures. If the temperatures don’t drop rapidly when the computer is idle, you probably need new thermal paste.