Meta Project Thoughts

As engineers/scientists whenever we embark on a new project we are generally full of enthusiasm and excitement, and are raring to get going. This is fantastic, and this enthusiasm should not be damped, but it is worth while to take a few moments to think about how you should record/backup the work that you are doing.

Project Name

Give a few minutes thought to the name of your project. The project name will hopefully be something catchy and easy to remember, and will bring out the key features you are investigating. You should avoid any brand names/company names.


One of the first tasks when undertaking a new project is doing a literature review. This will generally generate a lot of references (these may be published articles, websites, books etc). To quickly and easily record all these it is recommended to use a reference cataloguing system such as Zotero.


If a lot of your work is computer based (who’s isn’t these days?), then it is highly recommended to use some sort of version control system. The one with the most traction at the moment is called git. Git is certainly not easy and intuitive to use, but it is rather powerful. To make life a little easier, there is an online website called GitHub which removes some of the pain associated with using git.

Backing Up

It is very well to have a version control system to be able to review/recreate your work from any time in the past, but it is very important to realise that this is an archive and NOT a backup. At first glance, the version control system might seem like a backup, but it is simple to see the difference by thinking about what would happen if you wanted to look at an old version of a file, but discovered that the hard disk containing your repository had been corrupted. This old version would be gone forever, because it was only contained in the primary, active repository. This repository needs to be backed up. Another analogy is that of a state library. They contain many archives, but if the library burns down these are gone forever, UNLESS they have a copy (or back up) at some other location.

One of the very important criteria that I have discovered for a backup system is automation. If the backup system is not completely automatic then, in general, it simply will not be maintained.

If you are using GitHub rather than just git, you might decide that maintaining a cloud copy of your repository is sufficient backup. Otherwise, you could choose to back up to a local external hard-drive or use another cloud service.


A Google Docs folder can be useful for rapidly developing a list of resources/ideas for a project in collaboration with colleagues because it always for real-time co-authoring of a document, however there are a couple of issues to be wary of. Firstly, the contents of a Google Document does not exist ANYWHERE except on GOOGLE SERVERS or in closed-source GOOGLE APPS. I think that this is a major flaw/weakness in their system. There is no guarantee that you will be able to access this document in the future. You could forget/lose your account, google could cancel your account, somebody with whom you share the file could delete it. A possible solution to this is to continue to use google, but to periodically export the document to a docx/xlsx/pptx file, which can then be version controlled. Secondly, google drive does not work very well with git, and it is possible to break your repository if a folder is a git repository housed within a google drive directory.

There are other real-time collaboration tools available. If writing in LaTeX, these include ShareLaTeX and OverLeaf. Office 365 also has the ability to do real-time coauthoring, however I have not used this.

Look at your project from a variety of perspectives

Generally there is more than one way to think about any project. It can often be helpful to think about the project from a variety of different angles. For example, your project might use a variety of components so you might like to break your project down into the different components used. Your project will also generally require a variety of different skill-sets. You can divide your project up into the various skill-sets that you will need (e.g. coding, electronics, analysis).

Attaching the BlueBox to rotating machinery

Today the SHL managed to get a hold of an old and broken record player.

After disassembling the record player we discovered that the fault was a deteriorated elastic belt. We made do with what was available and replaced the belt with a piece of string. Whilst the record player was open we also replaced the wires running to the 12V DC motor with wires leading to a DC power supply unit. This allowed us to control the spin of the record player by varying the supplied voltage – the record player no longer just runs at either 33 or 45 revolutions per minute. We were then able to place a couple of BlueBoxes on the record player and get live data measuring the acceleration caused by the rotation of the disc bed.