Wie geht Softwaremanagement?

Service Team Forschungsdaten: Da du ja schon länger ein wahrer Data Champion hier an der LUH bist, dachten wir, es ist jetzt endlich mal an der Zeit, dass du auch dieses Interview mit uns machst. Vielleicht kannst du zu Beginn einfach mal erzählen, mit welchen Arten von Daten du hauptsächlich arbeitest.

Oliver Melchert: Die Hauptart an Forschungsdaten, mit denen ich in meinem Forschungsalltag arbeite, sind Computerprogramme. Computerprogramme, die ich selbst geschrieben und ausführlich getestet habe. Die benutze ich als Teil meiner Forschungsarbeit im Prinzip zu zwei Zwecken: Ein Zweck ist es, fundamentale Phänomene zu untersuchen, die auch in den Gebieten der Physik auftreten, für die wir uns interessieren. Und der zweite Zweck ist es, konkrete Experimente nachzubilden und zu erklären. Oder vorherzusagen, was in der gegebenen experimentellen Realität im Labor tatsächlich passiert. Die Programme benutze ich also für zwei Sachen: Fundamentale Forschung, wo es um Einsicht geht, und angewandte Forschung, wo es um Erklärungen geht. Und wenn ich mit diesen Computerprogrammen arbeite, so sind der Input, der Output und die Resultate meistens Daten-Files. Das können Zahlen sein oder - weiterverarbeitet - auch Plots, Grafiken, die dann die Basis für eine Diskussion in wissenschaftlichen Journalen bilden.

Service Team Forschungsdaten: Es ist ja schon sehr vielfältig, was ihr so macht. Das erfordert viel Übersicht und eben auch Forschungsdatenmanagement. Was würdest du sagen, ist aus deiner Sicht das Wichtigste beim Forschungsdatenmanagement und warum?

Oliver Melchert: Gute Frage. Und ich glaube, bei der Frage kann man auch gut differenzieren, was zum einen die Motivation angeht und zum anderen, was prozedural dahintersteckt, wenn man Forschungsdatenmanagement betreiben möchte. Also ich finde, das Wichtigste ist eine Art intrinsische Motivation, das zu tun. Und das ist immer leichter, wenn man einen Nutzen hat. Und der Nutzen für mich ist: Wenn ich geeignetes Forschungsdatenmanagement betreibe, kann ich meine Arbeit reproduzierbar machen. Und das hilft natürlich, meine eigene Arbeit in der Community populärer zu machen, sodass Leute sie aufgreifen. Von daher habe ich eine intrinsische Motivation.

Auf der anderen Seite ist Reproduzierbarkeit nicht immer einfach gegeben. Vorhin habe ich gesagt: Ich entwickle Software, und Eingabe, Ausgabe und Resultate sind Daten-Files. Es gehört natürlich auch noch mehr dazu. Nur weil ich ein Programm schreibe, heißt es nicht, dass jemand auch direkt damit arbeiten kann. Es muss gut dokumentiert werden, damit jemand lesen kann, was ich gemacht habe, um es dann sehr zügig selbst benutzen zu können. Forschungsdaten managen heißt für mich einfach, all die kleinen Aktivitäten als tägliche Routine anzuwenden, um es anderen oder mir selbst einfach zu machen, mit meinen Computerprogrammen zu arbeiten. Und je nachdem, wie gut das gelingt - da gehört natürlich auch Erfahrung dazu -, desto weiter wandert man in so einem Reproduzierbarkeits-Spektrum hin zu „leicht reproduzierbar“.

Ich habe das selbst in der Vergangenheit gemerkt, wenn ich mit Codes von anderen gearbeitet habe. Nur weil es einen Artikel gibt, der erklärt, was passieren soll, und es den Code dazu gibt, heißt das nicht, dass alles ohne Weiteres funktioniert. Ich muss wissen, was hatten die für eine Umgebung, auf der der Code lief, damit ich den gegebenenfalls kompilieren und korrekt ausführen kann. Haben die vielleicht gewisse Datenauswertungs-Routinen verwendet, die für mich nicht offensichtlich sind? Mehr Kontext hilft, für jemand anderen leichter nachvollziehbar zu machen, wie ich zu den Ergebnissen kam, die zum Beispiel in einem Artikel dokumentiert sind.

Also je mehr ich an Aufwand betreibe, um zu erklären, was ich tue, desto leichter ist die Arbeit reproduzierbar. Und im Endeffekt ist die Reproduzierbarkeit der Hauptstandard, an dem die Gültigkeit von wissenschaftlicher Einsicht gemessen wird. Und das ist die intrinsische Motivation, Forschungsdatenmanagement zu machen.

Man muss eine Routine gewinnen. Für mich war das auch so, als ich das erste Mal angefangen habe, ein eigenes Projekt zu managen, hinsichtlich der Sicherung und des Erhalts der Forschungsdaten. Es war mühsam. Es hat lange gedauert und es war auch gar nicht so einfach. Aber je öfter man das macht, desto einfacher wird es. Mittlerweile habe ich Arbeitsroutinen. Wie gehe ich daran, ein Programm zu entwickeln? Wie dokumentiere ich es? Wie sind die Datenstrukturen, die ich verwende? Wie ist das Layout von den Input Files, den Output Files und den Resultaten, sodass es für andere Sinn ergibt? Wie verarbeite ich die wieder zu Bildern? Das alles funktioniert in ganz routinierten Mustern und ist damit gar kein Aufwand mehr, sondern ich weiß im Vorfeld, wie es läuft. Und dann lässt sich die Arbeit leicht strukturiert ausführen.

Forschungsdatenmanagement hilft mir dabei, meinen ganzen Alltag zu strukturieren. Und deswegen ist das Wichtigste, einfach damit anzufangen und die Routine zu gewinnen. Das ist immer dann einfach, wenn es in der Gruppe, in der man ist, schon Standards gibt, die quasi vorgeben, wie das zu erfolgen hat. Als ich das das erste Mal gemacht hatte, wusste ich noch nicht, wie es geht, habe aber davon profitiert, dass andere Leute in den Arbeitsgruppen waren, die mir gezeigt haben, wie es funktionieren kann. Also auf eine gewisse Weise müssen Standards da sein, vielleicht aufgeschrieben, vorformuliert in einem Dokument, oder es gibt eine Person, die Anleitung gibt. 

Es gibt aber auch noch ganz viele andere kleine Dinge, die muss man halt einfach machen, um sich im Alltag zurechtzufinden. Man sieht es schon daran, wie man in so einem Projektumfeld E-Mails schreibt. Schon allein der Betreff kann so nützlich sein, um für mich nachvollziehbar zu machen, wie es denn überhaupt dazu kam.

Und ich finde ganz, ganz oft zeigt sich in der Kommunikation, gerade via E-Mail, dass oft wissenschaftliche Arbeit auf eine recht unwissenschaftliche Weise gemacht wird, wenn die Betreffe zum Beispiel nicht da sind oder nicht zu dem passen, was in der E-Mail steht. Das macht es mühsam, Dinge zu suchen und zu rekonstruieren.

Das ist ein kleines Beispiel, aber für alle anderen Artefakte meiner Forschung gilt das genauso. Also, um nochmal auf die Grundfrage zurückzukommen: Das Wichtigste beim Forschungsdatenmanagement ist, es so anzugehen, wie die wissenschaftliche Arbeit selbst. Das ist meine Meinung.

Service Team Forschungsdaten: Du hast jetzt viel über Routinen und Standards gesprochen, also, dass man Regeln findet, an die sich dann alle halten, und dann kann eigentlich gar nicht mehr so viel passieren...

Oliver Melchert: So ist es. Ich meine, es ist nicht immer so, dass man in eine Arbeitsgruppe kommt, und dann gibt es da einen Software-Entwicklungsstandard oder eine Software-Entwicklungsmethodologie. Das muss es nicht unbedingt geben. Dann ist es immer nützlich zu gucken: Was machen denn so die anderen, die schon länger in der Arbeitsgruppe sind? Wie sieht das aus? Einem Beispiel zu folgen, kann Standards setzen, auf eine unaufdringliche Art und Weise. Und langfristig gesehen ist es immer nützlich, Sachen zu formalisieren und aufzuschreiben. Aber oft fehlt da die Zeit und die Manpower dafür, das sehe ich auch.

Forschungsdatenmanagement ist schwer zu etablieren, weil es historisch gesehen immer so nebenbei lief. Ich meine, die Bedeutung von Forschungsdatenmanagement hat sich mit der Zeit ein bisschen verändert, und ich weiß auch nicht, ob jeder über dasselbe redet, wenn er das Wort Forschungsdatenmanagement in den Mund nimmt. Von daher ist es auch immer noch so ein bisschen eine Blackbox, also ein Begriff, der nicht für jeden dasselbe meint. Und das macht es unglaublich schwierig. Für die einen ist Forschungsdatenmanagement, die Artefakte der Forschung, die Outputdaten, auf ein Harddrive zu packen und für zehn Jahre aufzuheben. Und für andere ist es halt auch noch, sicherzustellen, dass die Betreffe in der E-Mail Sinn machen. Es ist ganz, ganz ulkig, was sich hinter dem Terminus Forschungsdatenmanagement für unterschiedliche Personen eben verbergen kann. Und solange das nicht ganz einheitlich ist, ist es halt auch schwierig zu erwarten, dass alles auf eine standardisierte Art und Weise geschieht.

Service Team Forschungsdaten: Du nutzt wahrscheinlich immer die gleichen Tools, mit denen du gut klarkommst, bei denen du weißt, wie die funktionieren. Welche Tools benutzt du für dein Datenmanagement, und wie sind deine Erfahrungen?

Oliver Melchert: Wenn ich an meinem Computer sitze und an einem Projekt arbeite, dann sind das meist kleine selbstgeschriebene Programme, die mir helfen, die Daten, die ich bisher erhoben habe, nach bestimmten Gesichtspunkten zu durchmustern. Aber für das darüberhinausgehende Forschungsdatenmanagement, also wenn ich meine Forschungssoftware zur Verfügung stellen möchte für andere, da nutze ich GitHub. Wieso nicht GitLab? Zu dem Zeitpunkt als ich begonnen habe, GitHub zu verwenden, gab es GitLab noch nicht. Von daher ist es GitHub, und ich nutze es für unterschiedliche Zwecke.

Zum einen natürlich, um meine Software anderen zur Verfügung zu stellen. Im Bewusstsein, dass ich meine Software öffentlich verfügbar mache, lege ich da noch mal ganz anders Hand an, sodass ich ein gutes Gefühl habe, sie aus der Hand zu geben. Ich sehe, die Peers schauen mitunter drauf, und deswegen soll der Code sauber sein. Und das motiviert mich dann auch mehr, an das Thema Forschungsdatenmanagement selbst heranzugehen, als wenn der Code einfach auf meiner eigenen Festplatte verstauben würde.

Also, wie gesagt, primär nutze ich GitHub, um meine Research Software zugänglich zu machen. Aber ich nutze es auch als eine Art Versionskontrollsystem, weil ich meine Software da pflegen und auf ältere Versionen zurückgreifen kann. Es nimmt mir somit das Versionieren ab. Auf der anderen Seite hilft es mir auch kollaborativ zusammen mit Studierenden bei uns in der Arbeitsgruppe ihre Studierenden-Projekte oder Masterarbeiten zu schreiben, Code zu entwickeln, zu testen oder zu reviewen.

Und für alle anderen Dinge, außer Code, die ich gerne ablegen möchte, nutze ich Zenodo, zum Beispiel, wenn ich auf einer Konferenz ein Poster vorstelle oder für andere Medien.  Wenn ich nicht weiß, wie ich die sonst verfügbar machen sollte, nutze ich gerne Zenodo, aus zweierlei Gründen: Der eine Grund ist, dort kann ich einen Digital Object Identifier für das Medium, das ich dort veröffentliche, bekommen und es damit auch zitierbar machen. Und zum anderen ermöglicht es mir, z. B. nicht nur Poster, sondern auch Datensets abzulegen und diese dauerhaft zu archivieren. Abseits von den Strategien, die sowieso durch die Institute gegeben sind. Die beiden (GitHub und Zenodo) finde ich sehr praktisch.

Service Team Forschungsdaten: Und nutzt du GitHub auch direkt zur Dokumentation?

Oliver Melchert: Gute Frage. Typischerweise ist es so, dass ich den Code lokal bei mir auf dem Computer entwickle und die Dokumentation in die Files direkt mit hineinschreibe. Meist ist es so, wenn ich Code entwickle, und ich noch nicht genau weiß, wie das Codestück, das ich schreiben möchte, aussehen soll, dann schreibe ich die Dokumentation zuerst. Und tatsächlich schreibe ich die Dokumentation zuerst in meinem Program-File und im Nachhinein, wenn die Arbeit erledigt ist, lade ich die Sachen erneut auf GitHub hoch, sodass diese an einem geeigneten Ort abgelegt sind. Aber darüber hinaus habe ich für größere Projekte auf GitHub die Möglichkeit, eine sauber gepflegte Online-Dokumentation zu erstellen, auf denen Beispiele gezeigt werden und der Code besprochen wird. Dabei handelt es sich um Anmerkungen, die nicht im Code vorhanden sein müssen, um diesen einsichtiger zu machen, sondern die den Kontext erklären. Das ist eine Art Online-Dokumentation, die ich dann auch via GitHub zur Verfügung stelle. Da finde ich GitHub sehr praktisch, weil ich dort sowohl den Code hochladen als auch die Dokumentation hosten kann.

Service Team Forschungsdaten: Hast du schon einmal Software von anderen selbst genutzt? Und wenn ja, welche Erfahrungen hast du dabei gemacht?

Oliver Melchert: Ja, tatsächlich recht häufig. Das erste Mal, dass ich mit der Software-Arbeit im wissenschaftlichen Sinn in Verbindung gekommen bin, war während meiner Diplomarbeit an der Universität Gießen. Da habe ich eine kleine, wohl umrissene Codebasis bekommen. Meine Diplomarbeit hatte ich in Zusammenarbeit mit einer Uni in Budapest gemacht, und die Codebasis, die ich bekam, war aus der Uni in Ungarn. Da waren ein Teil der Dokumentation und die Variablenbenennungen auf Ungarisch, das hat mir nicht geholfen. Und die Erfahrung, die ich dabei gewonnen habe, ist, Code richtig zu zerlegen, also Reverse Engineering zu betreiben, um zu verstehen, was da passiert. 

Eine andere Erfahrung war, als ich als Doktorand in einer Arbeitsgruppe angefangen habe. Mein Doktorvater hat nicht nur Physik, sondern auch Informatik studiert. Und das erste Projekt, was ich bekam, war eine Codebase von ihm. Es ging um komplexe Grundzustände ungeordneter Systeme, also konkret um Domänenwände in Spin-Gläsern. Der Code, den ich von ihm bekam, war in der Programmiersprache C, und der war extrem gut ausgearbeitet. Er war sehr modular aufgebaut und ich hatte bis dato so etwas noch nicht wirklich gesehen. Von daher hat mich das ein bisschen eingeschüchtert. Aber der Code war so extrem gut dokumentiert, dass ich ihn zügig nachvollziehen konnte. Ich habe das dann später auch als Vorbild genommen, um zu sehen, wie man geeignete Datenstrukturen implementieren kann und wie man modularen Code nicht nur anlegt, sondern auch organisiert, sodass weitere Leute sinnvoll damit arbeiten können. Das hat mir sehr viel darüber gezeigt, wie man sauber Code entwickelt.

Service-Team Forschungsdaten: Also hast du sowohl aus den positiven als auch den negativen Beispielen gelernt, wie du es am besten machst?

Oliver Melchert: Ja, so ist es. Also das waren jetzt zwei Beispiele. Es gab noch weitere Sets an Forschungscode, mit denen ich gearbeitet habe, wo dann jeweils ersichtlich wurde, wie nützlich es ist, gewisse Datenstandards einzuführen. Im Prinzip kann man aus allem, was professionell gemacht wird, immer etwas Gutes herausziehen. Ich bin Physiker und meine wissenschaftliche Arbeit geht meistens um irgendein Phänomen in dieser Anwendungsdomäne. Und da muss ich Domänenexperte sein. Das heißt, im Endeffekt zielt meine ganze Arbeit darauf ab, irgendetwas in der Physik zu erklären. Und oftmals reflektiert der Code, den man selbst oder Kollegen schreiben, genau das. Also der Fokus liegt auf dem physikalischen Modell. Einige der Codebases, mit denen ich bisher arbeiten konnte, waren da anders geartet. Da ging es wirklich nur um das effiziente Implementieren von numerischen Methoden und wie man das in einer gewissen Programmiersprache tut. Und da konnte ich viel darüber lernen, wie man Code schreibt und entsprechend den Versuch starten, alles sehr, sehr sauber zu halten, wie auch diese Vorbilder das tun.

Service Team Forschungsdaten: Kommen wir zur letzten Frage: Welche Entwicklungen wünschst du dir in den nächsten Jahren im Bereich Management von Forschungsdaten? Also zum Beispiel in Bezug auf Richtlinien, Anreize, bessere Tools oder Dienste, die du benötigst.

Oliver Melchert: Eine Sache, die ich erfahren habe, auch durch meine eigene Arbeit als Gutachter für bestimmte Journale, ist, dass es häufig Fälle gibt, in denen Forschungssoftware außerhalb ihres Gültigkeitsbereiches verwendet wird. Oftmals ohne Wissen derer, die sie nutzen. Und das verursacht das Problem, dass die Interpretation der Resultate, die daraus entstehen, schlichtweg falsch oder irreführend ist. Das ist ein großes Problem und ich bin der Meinung, das lässt sich durch geeignete Tests vermeiden. Daher, würde ich mir langfristig wünschen, dass in der Forschungsarbeit Raum geschaffen wird, sodass man Codebases, die man bekommt, ausführlich testen kann und die Tests der Community zugänglich macht. Ich meine, es gibt einige Journals, die es ermöglichen, Software zu publizieren, aber das tue ja dann ich als Autor der Software. „SoftwareX“ ist zum Beispiel so ein Journal, bei dem ich selbst auch publiziert habe, oder „Computer Physics Communications“, wo ich meine getestete Software veröffentliche. Aber es wäre auch sehr nützlich, wenn die eigene Software getestet und Erfahrungsberichte darüber geschrieben und veröffentlicht würden. Tatsächlich gibt es so etwas online auch schon: ein Journal, das auf GitHub betrieben und abgelegt wird. Das nennt sich „ReScience C“. Das testet dann, wie reproduzierbar gewisse Studien sind, die publiziert wurden. Und ich denke, Software zu testen wäre extrem nützlich, sodass langfristig auch sichergestellt werden kann, dass Software nicht außerhalb ihres Gültigkeitsbereiches verwendet wird, was, denke ich, ein großes Problem ist.

Service-Team Forschungsdaten: Also eine Art TÜV für wissenschaftliche Software?

Oliver Melchert: So ist es! Es kommt tatsächlich regelmäßig vor, dass Software außerhalb ihres Gültigkeitsbereiches verwendet wird und die Ergebnisse verkehrt sind. Katastrophal!

Service-Team Forschungsdaten: Allerdings bräuchte es dafür wahrscheinlich dann auch entsprechende Richtlinien, weil das nur Sinn hat, wenn es eine gewisse Verpflichtung gibt, seine Software einem solchen Test auch zu unterziehen. Und das heißt, da müsste es auch eine fachspezifische Policy geben, wo es heißt, wer Software schreibt, der muss die so und so testen lassen.

Oliver Melchert: Ja, das stimmt. Eine Grundvoraussetzung ist, dass die Software auch verfügbar ist für das Testen. Und mir hat die Vergangenheit eins gezeigt: Es gibt oft nützliche Kritik, in der auf einen Bug hingewiesen wird. Die Leute sind froh, dass sie die Software verwenden können und haben eine Follow-up-Frage: Wie kann ich das dann in dem und dem Kontext verwenden? Und dann hat sich ebenfalls gezeigt, dass oft auch noch eine kleine Kollaboration damit verbunden ist, sodass man bestimmte Aspekte in der eigenen Software zusätzlich implementieren und somit den Nutzungsbereich der eigenen Software erweitern kann. Das ist super. Alles wird besser dadurch!

Service-Team Forschungsdaten: Ein super positives Schlusswort. Ganz herzlichen Dank!