We strive to help anyone, who is new to software development to make advances with his/her software engineering skills. From our own experience we know how hard this can be and that getting all the systems and best practices to work can feel very challenging. But from our own experience we know also, how annoying it is, to try to work with (or even expand) software from others which is complex and was written without following best practices.

We are proposing a workflow developed in the SFB 1194 at TU Darmstadt that is modular and tested - just as your code will be if you apply the workflow. At the same time it introduces little overhead at project start while reducing effort and error-proneness over the whole project lifetime.

The good news: already with a set of only few practices, you should be able to improve your code quality significantly. These we have bundled in the minimum workflow.
To make your code fully FAIR (Findable, Accessible, Interoperable and Re-usable) there are some more topics that need your attention. Those are bundled in the full workflow.

Scientific legacy code

It is bad practice when code is…

  • only partially tested (or even worse: not at all)
  • testing is not automated
  • the code is not documented or the documentation is not helpful e.g. not up-to-date
  • there are different versions of the code, especially, if they are not compatible.

If your code has one or more of the traits listed above, we believe it is doomed to be abandoned in the long term.

Reasons for bad scientific code quality

Emphasis and rewards

The academic world puts its emphasis on the results you show in your papers. While results are important, the code is usually not considered a result and therefore you get little credit for writing the best code in the world.


At the same time the focus of software development is on the output of papers (as discussed above), there often is no specific funding for improving or even maintaining the software quality.

High fluctuation

Usually project members rotate often e.g. as the PhD-study related employment expires. This leads to project contribution times of typically 3-5 years. Additionally there might not be any overlap between the predecessor and the following person, restraining the transfer of knowledge.

Study curriculum

Software development or research software engineering is not taught in-depth to scientists like mathematicians or physicists, or engineers. When going through PhD studies, these researchers might have to write code though. Similarly in industry, it is not uncommon for members of these professions to work with code.

Your benefits

Potential benefits of a structured workflow leading to sustainable software development for you as a researcher can include, but are of course not limited to:

  • faster software development
    • automatized workflows
    • less effort for documentation is required
    • no diverging versions
  • ability to reproduce your own results
  • ability of others to reproduce your results
  • confidence in your code
    • your developments don’t break other software features
    • your code is tested with Verification & Validation (V&V) tests
  • higher probability of the software project to flourish for years to come
  • supervised students can support you after less training period

Where to start

Continue with the page Getting started to learn more about the methods and tools we propose.
Continue with the literature regarding the workflow to learn more about the motivation and the workflow we propose.

See also