Der Softwareentwickler und Wissenschaftler Martin Hammitzsch hat an der Entwicklung von Frühwarnsystemen für Naturgefahren mitgearbeitet. Seit 2015 organisiert er gemeinsam mit Kolleginnen und Kollegen Software Workshops für Nachwuchswissenschaftlerinnen und -wissenschaftler. Im Interview sprechen wir mit ihm über die Bedeutung von Software in den Geowissenschaften, aktuelle Entwicklungen und Herausforderungen.

GFZ: An wen richten sich die Kurse zum Thema Software Writing?

Martin Hammitzsch: Zielgruppe sind programmierende Wissenschaftlerinnen und Wissenschaftler. Insbesondere junge WissenschaftlerInnen, Studierende in ihrem Master, PhDs und PostDocs, aber auch gestandene WissenschaftlerInnen, die ihren Horizont erweitern möchten. Prinzipiell wollen wir alle ansprechen, die irgendwie mit Software zu tun haben, aber insbesondere die, die sich ihre Programmierkenntnisse selber aneignen. Wichtig sind uns die Vermittlung handwerklicher Fähigkeiten und ein besseres Verständnis im Umgang mit Software. Dadurch gewinnen WissenschaftlerInnen nicht nur mehr Zeit für die Forschung sondern es erhöht auch die Qualität der Arbeit.

GFZ: Es sind also in erster Linie keine IT-ler, sondern Geowissenschaftlerinnen und -wissenschaftler, die Software als ein Werkzeug für ihre Forschung nutzen?

Hammitzsch: Genau. Wir zeigen, was es alles schon gibt, so dass nicht jeder bei Null anfangen und sich alles selbst erschließen muss.Im Grundlagenkurs geht es auch darum, Code überhaupt erst zu verstehen. Wir wollen Hintergrundwissen zur Programmierung vermitteln und einen Austausch ermöglichen.

Ein wichtiger Aspekt der Kurse ist das Thema Nachnutzung von Software. Wenn beispielsweise ein PhD das Institut verlässt, möchte natürlich seine Sektion den Code, den der PhD geschrieben hat, weiterverwenden können. Der Schreiber des Codes muss dafür über entsprechende Kompetenzen verfügen und bestimmte Regeln beherzigen. Man sollte Software als Teil einer Infrastruktur begreifen, der auch gepflegt werden muss.

Jemand, der wissenschaftlich arbeitet, muss auch erst lernen Publikationen zu schreiben und seine Ergebnisse zu veröffentlichen. Dazu gehört das Wissen über Standards des wissenschaftlichen Schreibens, die innerhalb einer Community gelten oder die durch die Fachzeitschrift vorgegeben werden, in der man publizieren möchte. Genauso ist es auch im Bereich Software.

GFZ: Sie sagen in der Kursbeschreibung, dass das Schreiben von Code auch in der Geowissenschaft minimalen Ansprüchen genügen sollte. Was genau ist damit gemeint?

Hammitzsch: Das betrifft den Einsatz bestimmter Standardwerkzeuge und Prozesse aus dem Softwareengineering. Dazu gehören zum Beispiel die Versionskontrolle, der Umgang mit Daten und der Einsatz automatisierter Prozesse. Minimale Ansprüche an Code betreffen aber auch Themen wie Strukturierung, Modularisierung oder die Vermeidung von Duplikaten. Von hundert Weisheiten aus dem Softwareengineering sind für mich als codenden Wissenschaftler vielleicht zehn schon völlig ausreichend, um meine Arbeit deutlich besser gestalten zu können. Die sollte ich kennen.

Auch das Vermeiden einer frühzeitigen Optimierung ist wichtig. Viele meinen, sie müssten möglichst früh alles generisch aufbauen und optimieren. Besser ist, zunächst den eigentlichen Sachverhalt zu lösen und im Nachhinein den Code eleganter zu machen. Software sollte außerdem nicht alleine im Raum stehen, geschrieben in kryptischem Code. Die einheitliche Benennung von Variablen und Funktionen ist wichtig. Das ist keine Selbstverständlichkeit, oft stößt man auf sehr kuriose Bezeichnungen. Außerdem braucht Software begleitende Informationen in Form einer nachvollziehbaren Dokumentation.

Das alles ist natürlich zusätzliche Arbeit. Aber sie lohnt sich, insbesondere dann, wenn man in einer Gruppe programmiert. Auch ist so nicht gleich ein ganzes Projekt gefährdet, wenn jemand ausfällt. Aber auch, wenn man alleine entwickelt und seinen eigenen Code nach einem halben Jahr weiter bearbeiten möchte, merkt man, wie wichtig gut strukturierte Software und eine gute Dokumentation sind.

GFZ: Wie lässt sich sicherstellen, dass Software weiter zugänglich ist, wenn die Leute, die sie erstellt haben, weg sind?

Hammitzsch: Der Einsatz von Web-basierten Plattformen und Tools für die Verwaltung von Softwareprojekten und Softwareentwicklungsprozessen spielen eine große Rolle. Solche Plattformen sind beispielsweise GitHub, Bitbucket oder Sourceforge. Darüber kann die Zusammenarbeit von zwei nebeneinander sitzenden KollegInnen aber auch die Zusammenarbeit großer, internationaler Teams sichergestellt werden. Darüber hinaus erlauben die Web-basierten Tools nicht nur den Austausch zwischen EntwicklerInnen untereinander sondern auch mit nicht-programmierenden NutzerInnen.

Allerdings sind darüber verwaltete Softwareprojekte öffentlich, wenn man nichts zahlen möchte. Man kann aber auch, wie bei einer schriftlichen Publikation, erst einmal innerhalb eines geschützten Raums arbeiten, beispielsweise mit GitLab als institutseigenem Tool. Als Institution kann es sinnvoll sein, hierfür Richtlinien vorzugeben, an denen sich programmierende Wissenschaftlerinnen und Wissenschaftler orientieren können, unabhängig vom Umfang der Software.

GFZ: Bei schriftlichen Publikationen oder Daten gibt es die DOI, den Digital Object Identifier, über die eine Publikation den UrheberInnen zugeordnet werden kann. Wie lässt sich bei Software sicherstellen, dass sie referenzierbar ist?

Hammitzsch: Auch für Software gibt es DOIs. Relativ bekannt ist, dass man Versionsstände die in GitHub vorliegen, zum Beispiel über Zenodo - eine Plattform für die Publikation, gemeinsame Nutzung und langfristige Speicherung wissenschaftlicher Daten und Software - als einfaches Zip-Paket publizieren kann. Da wird ein Großteil der entsprechenden Metadaten direkt mitgeliefert: Wer sind die AutorInnen, wie heißt ein bestimmtes Stück Software, in welcher Version liegt es vor und so weiter.

Die Zip-Datei wird zusammen mit Metadaten in einer Datenbank archiviert und bekommt eine Nummer: die DOI. Für die Langzeitarchivierung und Zitierung mag das ausreichend sein. Die Software wird dabei aber komplett aus dem Projekt herausgelöst. Es geht viel verloren, wenn man Lösungen des Publikationswesens für unveränderbare PDF- und Print-Veröffentlichungen auf Software übertragen möchte. Das wird dem dynamischen Charakter von Software einfach nicht gerecht.

GFZ: Wie wird damit umgegangen?

Hammitzsch: Sehr häufig geht der Weg noch über eine schriftliche Publikation. Es wird also ein Fachtext über eine bestimmte Software veröffentlicht. Wer die Software nutzt wird dann darum gebeten, diese Publikation zu zitieren. Dadurch ist aber keine Nachvollziehbarkeit oder Reproduzierbarkeit garantiert, weil so zum Teil schon längst veraltete Publikationen ständig weiter zitiert werden. Die Software dahinter wurde aber vielleicht schon längst weit über den in der Publikation beschriebenen Stand hinaus entwickelt. Ob ältere oder neuere Versionen einer Software überhaupt noch dieselben Funktionalitäten haben, die sich NutzerInnen erhoffen, ist dann gar nicht klar. Da gibt es noch eine große Lücke.

GFZ: Sind da die Institutionen auf dem richtigen Weg?

Hammitzsch: Ich denke, dass Software oft noch recht stiefmütterlich behandelt wird, obwohl die Softwareentwicklung heute ein elementarer und unverzichtbarer Bestandteil der Forschungstätigkeit ist und der Erkenntnisgewinn oft maßgeblich von ihr abhängt. Wissenschaftliche Software und die damit verbundene Arbeit sollte innerhalb der Forschungstätigkeit die Aufmerksamkeit und Anerkennung erhalten, die ihr gebührt.

GFZ: Was sind Best Practices auf die Sie gerne verweisen? Wo wird Software vorbildlich entwickelt?

Hammitzsch: Aktuell ist in der GFZ-Sektion Hydrologie der Einsatz von Versionskontrollsystemen nach klar definierten Kriterien geplant. Hier soll die Versionsverwaltung verpflichtend sein für Software mit zwei oder mehr EntwicklerInnen, für Software, die als allgemeines Werkzeug für die Arbeitsgruppe angesehen wird, und von Anfang an für alle neuen Softwareprojekte und Software-entwickelnden DoktorandInnen und MitarbeiterInnen.

Außerdem gibt es Softwareprojekte wie zum Beispiel SeisComP3. Ursprünglich für das GEOFON-Programm entwickelt, werden damit seismische Daten prozessiert. Mittlerweile wird die Software sogar von der UNO zur Überwachung des Atomwaffenteststopp-Abkommens eingesetzt. Oder EQUATOR II, ein System, das Erdbebenparameter, Kontextinformationen und Bewertungen von ExpertInnen zu einem Gesamtbild aufbereitet. Beides sind GFZ-Projekte die auf stabilen Beinen stehen und bei denen Weiterverwendung und Nachnutzung garantiert sind.

Wichtig ist vor allem, dass es einen Austausch über diese Best Practices gibt und man voneinander lernen und aufeinander aufbauen kann. Es ist einfach gut, wenn bekannt ist, welche Software gerade wo entwickelt wird. Auch dafür sind unsere Workshops da. Manchmal sind es schon kleine Skripte oder Teile innerhalb von Programmcodes, die anderen sehr weiterhelfen können. Da könnte noch sehr viel mehr passieren und offengelegt werden, um das gesamte vorhandene Potenzial zu nutzen.

GFZ: Wie sieht die Zusammenarbeit zwischen Ihnen und den WissenschaftlerInnen aus?

Hammitzsch: Wenn ich als IT-Experte mit einem Hintergrund im Softwareengineering mit WissenschaftlerInnen zusammenarbeite, muss ich zunächst verstehen, was die Leute überhaupt wollen, zu welchen Erkenntnissen wollen sie kommen? Das ist ein iterativer Prozess, der viel Kommunikation voraussetzt. Es gibt nie nur die eine, sondern unterschiedliche Lösungen mit unterschiedlicher Komplexität und verschiedenen Vor- und Nachteilen, aus denen man eine passende auswählen muss.

Der Idealfall ist, dass SoftwareexpertInnen schon am Beginn eines Projektes beteiligt werden und über Anforderungen und Machbarkeiten gesprochen wird. Insbesondere, wenn Software in einem Projekt eine wichtige Rolle spielt. Und dabei meine ich nicht Standardsoftwareprodukte, sondern Software, die speziell für einen bestimmten Anwendungsbereich entwickelt wird. Es muss klar sein, wie die Software in einem Projekt verwaltet werden soll, genauso, wie das beispielsweise auch für Daten gilt.

GFZ: Erkennen Sie eine steigende Tendenz hin zu mehr digitalisierten Prozessen in den Geowissenschaften für die neue Softwarelösungen gefunden werden müssen?

Hammitzsch: Ja, definitiv. Immer mehr Software ist im Einsatz und ich glaube auch, ohne geht es gar nicht mehr. Meistens hat man es in irgendeiner Form damit zu tun, dass Daten erfasst werden und Daten sind heute digital und werden von Softwaresystemen erfasst. Dann beginnt die Kette der Prozessierung, in der die Daten aufbereitet und verarbeitet werden müssen, so dass am Ende ein Erkenntnisgewinn steht. Daten können nicht ohne ein System leben und das ist heute eben in der Regel ein Softwaresystem.

GFZ: Was sind Chancen der Digitalisierung in den Geowissenschaften?

Hammitzsch: Nehmen wir das Feld der Frühwarnung. Das bekannteste System ist das deutsch-indonesische Tsunami-Frühwarnsystem GITEWS, das unter der Leitung des GFZ implementiert wurde. Aber es gibt auch weniger bekannte europäische Projekte für den Atlantik und das Mittelmeer, bei denen das GFZ Partner war. Diese Systeme aus Messstationen und Sensornetzwerken arbeiten zum Teil hoch automatisiert.

Man könnte einen menschlichen Operator davor setzen, der sich rund um die Uhr alle eingehenden Daten anschaut und sie auswertet. Das kann aber auch ein Softwaresystem. Wenn basierend auf aktuellen Messdaten berechnet wurde, dass es zu einem Tsunami kommen könnte, wird automatisch eine Nachricht mit den wichtigen Informationen erstellt, beispielsweise zu Wellenhöhen und Ankunftszeiten. Ein Operator muss dann nur noch die Ergebnisse der Simulation anschauen und überprüfen. Aber er muss eben nicht mehr alles selber bedienen. Das ExpertInnen-Wissen bleibt weiterhin gefragt, auch als Korrektiv, aber das Softwaresystem nimmt bei der Auswertung und Bewertung eine Menge Arbeit ab. Das gleiche Prinzip lässt sich auf verschiedenste Systeme übertragen.

GFZ: Was ist Ihr Hintergrund? Wie sind Sie zum Experten für Softwareentwicklung in der Geowissenschaft geworden?

Hammitzsch: Los ging es bei Siemens mit einer Ausbildung zum Industrietechnologen mit hohem Softwareentwicklungsanteil. Danach habe ich in Berlin „Communication Systems“, also Nachrichtentechnik studiert und das Studium später in Potsdam am Hasso-Plattner-Institut fortgeführt, im Bereich „Software Systems Engineering“. Parallel habe ich in studentischer Tätigkeit und später hauptberuflich in der Wirtschaft gearbeitet und Software für Web-basierte Anwendungen entwickelt, bevor ich 2008 ans GFZ gekommen bin, um hier Softwaresysteme im Bereich Frühwarnung bei Naturkatastrophen zu entwerfen und zu implementieren.

GFZ:Wann sollen die nächsten Software Workshops stattfinden?

Hammitzsch: In der dritten Maiwoche in diesem Jahr. Neben uns sind auch das Potsdam Institut für Klimafolgenforschung, die Universität Potsdam und  KollegInnen anderer Partnerinstitute und –universitäten beteiligt. Aus anderen Ländern werden auch weiterhin über das Netzwerk der SoftwareCarpentry Kolleginnen und Kollegen dabei sein. Es ist geplant, dass Inhalte zu Grundlagen aber auch institutsspezifische Themen in hands-on lessons vermittelt werden.

11.05.2017

Das Interview führte Ariane Kujau

<link zentrum fort-und-weiterbildung software-writing>>>Software Writing workshops am GFZ