Because good research needs good data

Coding confessions – a template to share FAIR failures?

Patricia Herterich | 09 November 2021

At SeptembRSE, some collaborators and I ran a panel on Coding Confessions. Coding Confessions was created as part of the hackday at the Software Sustainability Institute (SSI)’s Collaborations Workshop 2021 as an initiative to change the culture of disclosing mistakes and build a collection of stories highlighting failures and lessons learned from them. 

One of the reasons why I am involved in Coding Confessions is that I like the idea and think it could be useful to also promote the adoption of the FAIR principles. Adhering to the principles can be difficult and sharing some of the experiences from researchers and data stewards who have tried to make data FAIR and struggled might be useful. So, should we have FAIR confessions? If so, do they need a different approach from Coding Confessions or can the Coding Confessions approach just be re-used? We’d love to hear your thoughts. 

Below is a repost of the blog about the Coding Confessions panel published on the SSI’s website at https://www.software.ac.uk/blog/2021-11-09-coding-confessions 

Introduction

Everybody who develops software has at some point written some software badly, quickly, cut corners or simply made a mistake that made it function incorrectly. The current research culture does not encourage sharing these mistakes openly, thus making it difficult for others to learn from others’ unsuccessful attempts and avoid similar issues.

Coding Confessions was created as part of the hackday at the SSI’s Collaborations Workshop 2021 as an initiative to change the culture of disclosing mistakes and build a collection of stories highlighting failures and lessons learned from them. The initial hackday project included creating a page where submissions can be added and writing guidelines to run a Coding Confessions session at events. 

Our first Coding Confessions Event: SeptembRSE 

SeptembRSE, the Society of Research Software Engineering’s conference provided the ideal opportunity to try out these guidelines and organise a panel to invite the community to confess to some mistakes.

Panellists were invited through an open call published on the Research Software EngineersSSI FellowsTuring Way and Open Life Science Slack channels as well as on Twitter. Furthermore, the organisers contacted candidates in their network to ensure a gender-balanced panel.  

The final panel comprised Graham Lee (University of Oxford), Magnus Hagdorn (University of Edinburgh), Ed Bennett (Swansea University), Jannetta Steyn (Newcastle University), Yo Yehudi (Wellcome Trust), and Becky Arnold (Keele University). Their confessions ranged from embarrassing typos in git commit messages, situations when core code for financial databases stopped working and needed to be fixed on urgent timelines, issues with code supporting PhD research as well as core aspects of enterprise solutions not working for customers.

Lessons Learned

  • Know your tools, understand what the library was created for and if it’s really suitable for your solution
  • Being lazy can be good
  • Being lazy can also be bad
  • Document your stuff (and ask others to do the same)
  • Don’t be ashamed to ask for help if it was a genuine mistake
  • Don’t blindly believe the hype about technologies
  • Testing is not optional
  • Close files and free resources when you don’t need them any longer 
  • Ensure that what’s in the loop needs to be in the loop (“Don’t open new connections in a loop”)
  • Test with more data than you’ve been given to ensure it scales
  • Simplicity correlates with efficiency
  • Don’t use anything deprecated, take the hit early and reworking it
  • Pick a few tools that will do the job well
  • You can test your system really well but you still won’t test for every eventuality. Users can be very good at finding the situations you didn’t test for and breaking your software.
  • Don’t leave somebody who’s just started a job with complete responsibility to run a production system without help

Most of the stories that were shared resonated with the audience, highlighting the importance of sessions like this where experiences can be openly shared. It also shows how even experienced software developers make mistakes. New software developers shouldn’t feel scared when they make these mistakes.

In addition to hosting the panel, we also had a poster that allowed SeptembRSE attendees to submit their coding confessions anonymously.

How the event went

Overall this first coding confessions event went quite well. A lot of effort went into trying to get a panel with an even gender split, but this is made difficult by having a community which is male dominated. There were worries at the start that nobody would be willing to confess their past mistakes; fortunately this proved to be untrue. People who were quite established in their careers were intentionally targeted. It was hoped this would help encourage more junior people to submit anonymous confessions. It was also thought that established people would have more stories to choose from and ones which weren’t so recent and that would be less risky to confess. Perhaps in future events it would be worth targeting some mid or even early career people too. 

Find out more

Acknowledgements

The authors would like to thank the session panelists for sharing their confessions, the SeptembRSE organising team for hosting our panel session and the SSI for the financial support to compensate our panelists.