As a group we contribute towards reducing the effect of the rise and spread of antibiotic resistance.

We do this primarily by developing methods able to predict whether genetic variants confer resistance (or not) to specific antibiotics.

These methods can then be incorporated into the new generation of genetics-based clinical microbiology tools, as exemplifed by GPAS.

Our research, which often takes the form of software outputs, is therefore

  • Reproducible
  • Tested
  • Documented
  • Widely available


We aim to make our results available in such a way that others can easily reproduce our results, wherever practical. One way of doing this is to publish a jupyter-notebook on GitHub that recreates one or more of the figures in the manuscript, as we did for the papers describing BashTheBug or the CRyPTIC ECOFFs.

The computational requirements of both of these are small enough that we can use the amazing MyBinder service so that the notebooks can be launched and run in browser, so that the user does not have to install any software.

For other areas of our research, for example free energy calculations using molecular dynamics, the sheer size and number of the output files makes this more challenging, but we make available what we reasonably can. For example, in our study using free energy methods on the DNA gyrase and RNA polymerase of M. tuberculosis you can download a set of input files, again via a GitHub repo.

Finally, some areas of research, notably machine learning, we expect to be able to make fully available, and therefore reproducible, again via jupyter-notebooks stored in a GitHub repo.


We will follow software engineering best practices and include unit tests for our Python code that can be run by a standard framework (e.g. pytest). These will be setup using continuous integration (such as GitHub Actions) to automatically be run on push. In addition, we will monitor and publish the proportion of the code that is covered by such unit tests.


We will include docstrings and sensible comments in our Python code and, ideally, use tools like Sphinx to autogenerate documentation of the classes, methods and functions in our code. Where necessary we will also write simple tutorials that e.g. take the form of a jupyter-notebook with explanatory text in markdown. We may wish to also use tools, like linting, to ensure our code is readable and concise.


All of the above will be publicly available, usually via our group GitHub organisation. Where relevant all code will contain an appropriate, which will be as open as we are permitted, given that any IP we generate belongs to the University. All our papers will be accessible by all (Open Access) and we aim to submit all manuscripts to a recognised preprint server before submission, except where forbidden by a journal.