SINGEK BLOG: Software Development for Scientists

SOFTWARE DEVELOPMENT FOR SCIENTISTS

Imer Muhović

23/03/2018


Science is an inherently difficult field to work in. Today, more than ever scientists have to combine deep technical knowledge from different disciplines in order to create publishable work. Computational skills are expected from almost all scientists, however not everyone has acquired‚ them during their studies. This problem is amplified by the fact that a lot of scientific software is simply bad.

Whether this is by having poorly written documentation, buggy execution, complex installation procedures, no clear way of distributing software, or lacking any support from the authors, the developers of these tools are shooting themselves in the foot by limiting the use and impact of the tools that they have spent their valuable time on. The causes of such issues are up for debate, but what is certain is that all of us working in this field would benefit immensely from following some basic software development practices.

So the next time you are slaving away in front of your code editor, here are a few things to keep in mind:

  • You are not your end user.
    • The person who will be using your program will not have your level of expertise in software development and troubleshooting. They might be a Post-doc working in the same field, or they might be an undergraduate student from a distant country. Both of them should be able to use your tool with the same ease and understanding.
  • Has your tool ever been tested by anyone else?
    • We know it works on your machine, but that doesn’t mean much. For your tool to be acceptable for use in the real world you need to find a few testers to evaluate it. Make sure they are of different skill levels, ranging from completely non-technical to an expert in your field. Send them the installer and docs and ask them to actively try to break your tool. Leave them alone for a week, with absolutely no input from yourself. When you come back I guarantee they will have come up with cases that will break your tool that you would never have expected.
  • Does the documentation cover all scenarios the user could end up in?
    • Good documentation is invaluable and saves both you and the user from having to reply to each other’s emails. It must clearly convey how to install your tool, how to troubleshoot common issues, how to perform all of its intended actions, and would ideally offer a brief introduction to all the concepts you mention in it, with additional links to papers that offer more introduction to the field.
  • How will you distribute it?
    • You do not want to be the kind of author that distributes their code by email. GitHub accounts are free and allow you to keep your code in a visible, public place.
  • Will you actually support your tool after it is out?
    • You may have spent months cramped in front of a keyboard, painstakingly creating your masterpiece, but if you do not support your users, fix the bugs they discover, and offer improvements to your tool after it is out, you might just as well not have bothered working on it at all. In this case it will join the legion of orphaned GitHub repos, and papers with dead URLs, linking to promising tools, that never got a chance to shine because nobody was around to help it after it was published.

These are just common-sense tips, that any developer should follow, and I strongly believe that by making better tools we can lower the barrier of entry into science and give scientists more time to work on making new discoveries, and less time fighting against the tools they use.

About the author

Imer Muhović – ESR 15

I come from Sarajevo, Bosnia and Herzegovina. After obtaining my BSc degree in Genetics and Bioengineering at the International Burch University and halfway through my MSc, I started working as a QA Analyst at Authority Partners in Sarajevo. While outside my field of education, hard work and an analytical rigor obtained by a science education helped me excel in my work, and led me to spending two professionally satisfying years at that position.


 

1 reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *