By Melody Sandells, Software Sustainability Institute Fellow, and Research Fellow, Environmental Systems Science Centre, University of Reading

The first time I heard the term bus factor was at the Institute's 2013 Collaborations Workshop. In summary, it refers to the number of people who would have to be run over by a bus in order for that software to no longer be adequately maintained any more - a neat concept, or so I thought. I then realised my software has a bus factor of one, which is to say, just me, so I needed to spend more time thinking about why that is, and to distribute my software in some way.

So is the bus factor just a darkly amusing term to get us to think about how we approach our software? Two weeks later, my friend and colleague got hit by a HGV. I won’t mention her name as I don’t want this article to pop up in a search engine associated with her, although it wouldn’t take the detective skills of Poirot to find out. The last time I saw her was at the funeral of her PhD supervisor - himself a good friend and colleague - who also died young after he fell down the stairs on New Year's Day. All of a sudden, the bus factor was no longer just a flippant term any more. It has become one that haunts me.

Comments after their deaths have ranged from "45 years of experience lost" to "no-one knows how the satellite works". This I know to be untrue. They both worked on a European Space Agency satellite project where the structure is very strict. So, somewhere, there will be an Algorithm Theoretical Baseline Document (ATBD), a thick, detailed document that should tell you exactly how the satellite works. There will also be code, psuedo-code, and a large team of colleagues who can fill in for them. If nothing else, their legacy will live on.

Still, we should all think carefully about how we approach our research. An untimely demise isn’t the remote possibility you might think it is. On the other hand, planning for an early exit has led me to consider the following points. Firstly, passwords - would my colleagues even be able to get into my computer if I was no longer there? Then there is filing. Sometimes I struggle to find my own documents, so how can these be better arranged? Then there is the biggie, the software itself.

So, in my next proposal. I will specifically allocate time to finish off the software, tie up loose ends and release the finished product with all necessary documentation, and I will insist my students do the same before they move on to pastures new. Good practice is out there, we just need to make it part of our routine - just in case.