Why software is like a puppy

Why software is like a puppy

Friday 29 Mar 19
by Anne Lykke

Fun fact: Do you know your software history?

Even though software seems like a rather modern concept, the organisations ‘Software Heritage’ and ‘INRIA’ have proposed an initiative, where they ask UNESCO to preserve software.

The reason for this is that software forms our everyday lives – and is already part of our history.

Read more about this software preservation initiative here.


Join the conversation

Do you want join the discussions on software sustainability?

Find this Twitter-handle and join us:


Software is like a puppy – it needs attendance, maintenance and care, or it dies. This and many other points were on the agenda at a 2-day workshop called “Software in the life sciences: development, usability, sustainability”.

“Tell your funders and PI’s that software is like a puppy. Puppies aren’t free, you got to feed them, they will get old, and they will die. Funders don’t understand software – but they know about puppies.”

The words come from Carole Goble, Co-founder of the Software Sustainability Institute, University of Manchester, UK. She gave the opening speech at a software meeting, where almost 50 researchers, software engineers, bioinformaticians, and others working with software from the Novo Nordisk Foundation Research Centers where gathered.

Better Software - Better Research 

Software is just a necessary evil

Ok, we get it: software tools developed for life sciences must be treated like a pet with lots of love and attention – and time. But what do you do, when time is in short supply?

One of the main purposes of the Software Sustainability Institute is to drive local community training of researchers and instructors in order to professionalize software driven research and improve practices in research projects.

Carole Goble works to build sustainable software infrastructures for life sciences globally in all aspects of software from workflows, benchmarking, policies, guides, best practice to training and writing standards.

“Yes, we try to persuade people to use standards – that is a tricky one,” she says and laughs.

"Think about this: it takes 4-5 years of training to become a chef. But most researchers have zero hours of training in using software. That is kind of sad"
Carole Goble, Co-founder of the Software Sustainability Institute, University of Manchester, UK

Watch a short video from the workshop made by the Danish National Biobank here:

Sustainable software (no it’s not green)

She laughs, because the reality is that software, to many scientists, is perceived as a necessary evil. It just has to work once – maybe twice – to prove a point or process data. And to most scientists, software is not something that has to live up to a standard.

Some software is built to throw away (homemade scripts, for instance), but most software is actually built to be reused. And reviewers of scientific journals must, since 2011, be able to view the code. Therefore, software must be sustainable and live up to the FAIR rules: ‘Findable, Accessible, Interoperable, and Reusable’.

Can you “cook” good software?

So, how do you produce maintainable, sustainable software in academia? Software that can be maintained even though the developer is leaving for other positions. And when you don’t get funding to develop software per se, but rather to do discoveries within biology.

Luckily, there are some initiatives going on to train scientists in software, in version control etc. For instance, the Software Carpentry Lab – a community of instructors – train others in basic software tools such as GitHub.

According to Carole Goble, one of the other main challenges when it comes to developing and using software for life sciences is lack of proper training.

“Think about this: it takes 4-5 years of training to become a chef, and 10 years to become a head chef. But most researchers have zero hours of training in using software. That is kind of sad,” she says.


Niko and Kai introducing the workshop.

Critical mass of users

But where do we go from here, if life science researchers won’t take time to learn how to use software properly, they won’t pay for it, and they don’t value software? It will all change, when you experience a compelling event, for instance, if your research is retracted due to errors. Or if enough people start using your platform.

These statements come from the other keynote speaker, Tim Gardner. He has worked at, amongst others, Amyris and is now Chief Executive and founder of Riffyn – a company that cleans up data, so to speak, in order to make data sharing, tracking, and data analysis seamless.

“If you get a critical mass of users, your software becomes indispensable. For instance, people learn Python (a programming language) by themselves. It’s complicated – it’s a whole new language they have to learn – but they do it because others have told them that it’s awesome when you know it.”


About the workshop

The organizing committe consisted of Senior Researcher Nikolaus Sonnenschein and Researcher Kai Blin from the Novo Nordisk Foundation Center for Biosustainability, Technical University of Denmark as well as Bartlomiej Wilkowski from the Danish National Biobank, Statens Serum Institut, Denmark.

The purpose was exchange of experiences within the field of software amongst the Novo Nordisk Research Centers, but also to find solutions to the current challenges within software use and development in life sciences. Read more about the conference here. 

Some key points from the workshop

The attendees discussed the challenges and opportunities in smaller break-out sessions. From these discussions, they gathered some statements and rules that - if followed - should make development and use of software in the life sciences better and easier. As a result you should be able to do better science.


  • People developing research software should strive to be FAIR (findable, accessible, Interoperable, and reusable especially). This means that help and support should be just around the corner, so researchers can always find “software-support”.

  • It would be nice to have a common name for people working with software development in life sciences, so that researchers know how to find these (let’s call them research software engineers, RSEs), in the organisation.

  • There should be more focus on professionalisation of RSEs.

  • It would be useful to have a pool of RSEs available at an institutional level, just like the leading research universities in the UK.

News and filters

Get updated on news that match your filter.