4. Expert:innenforum „Nachhaltige Softwareentwicklung in NFDI4Culture“: Professionalisierung in der Entwicklung von Forschungssoftware

verfasst von: Aleksander Marcic (ORCID), Daniel Jettka (ORCID), Felix Bach (ORCID), Lisa Dieckmann (ORCID), Daniel Röwenstrunk (ORCID), Martin Albrecht-Hohmaier (ORCID), Anne Ferger (ORCID), Franziska Fritzsche (ORCID)

Einführung

Das NFDI4Culture Expert:innen Forum zum Thema Nachhaltige Softwareentwicklung kam am 22 November 2022 zu seinem vierten virtuellen Treffen zusammen. Eingeladene Expert:innen und NFDI4Culture-Mitarbeiter:innen diskutierten im Rahmen des Forums, wie Nachhaltigkeit von Forschungssoftware vorangebracht und weiter etabliert werden kann. Für das vierte Treffen hatte sich das Forum das Thema „Professionalisierung in der Entwicklung von Forschungssoftware“ gewählt. Der Themenkomplex umfasst zahlreiche Aspekte institutioneller, organisatorischer sowie individueller Art.

Unter individueller Professionalisierung kann hierbei beispielsweise die Weiterentwicklung von persönlichen Fertigkeiten einer einzelnen Entwickler:in verstanden werden. Hierunter fallen etwa Kenntnisse in Programmierung, Softwarearchitektur- und management, Versionierung, Dokumentation, Testing, DevOps-Fähigkeiten, aber auch Selbstorganisation.

Die organisatorische Professionalisierung schließt die Arbeit und Organisation von mehreren Personen und Organisationseinheiten (etwa Forschungsprojekten) mit ein, also Teamarbeit, Projektmanagement, den Umgang mit Weisungsbefugnissen und Verantwortlichkeiten, aber auch Entwicklungs- und Softwaremanagementpläne.

Institutionelle Professionalisierung betrifft Bereiche und Einheiten, in denen Rahmenbedingungen für die beiden anderen Bereiche geschaffen werden, etwa für DH-Curricula, die Ausbildung für Research Software Engineers (RSEs) und Infrastruktur für Forschungsprojekte, in denen Forschungssoftware entwickelt wird. Wichtige Akteure sind hier zum Beispiel Universitäten und ihre jeweiligen institutionellen Einheiten, aber auch Forschungsförderungsinstitutionen. Sie wirken maßgeblich an den möglichen Karrierewegen und Arbeitsbedingungen von RSEs mit.

Jeder der drei skizzierten Bereiche von Professionalisierung bietet andere Gelegenheiten Nachhaltigkeit in der Entwicklung von Forschungssoftware zu fördern. Beispielsweise erleichtert eine „professionelle” Dokumentation die Wartung, Anpassung und Erweiterung von Forschungssoftware. Sowohl auf individueller als auch auf organisatorischer und institutioneller Ebene lassen sich hier mögliche Maßnahmen formulieren: Weiterbildungsangebote, Standards, DFG-Anforderungen für Forschungsprojekte, etc.

Mit der Aussicht, weitere Termine zu den anderen Aspekten folgen zu lassen, wurde der Fokus zunächst auf die individuelle Professionalisierung gelegt – auch im Hinblick darauf, möglichst konkrete Handlungsansätze direkt aus dem Forum heraus entwickeln zu können.

Impulsvorträge

Als Grundlage für die gemeinsame Arbeit waren im Vorfeld sechs Impulse zu verschiedenen Aspekten des Themas von Expert:innen des Forums sowie eingeladenen Gästen zu folgenden Themen vorbereitet worden:

• Übersicht zu existierenden Initiativen aus der RSE-Community (ausgefallen)
• die Angebote und Aktivitäten der Cultural Research Data Academy von NFDI4Culture
• Professionalisierung in DH-Zentren am Beispiel des CCeH Köln (ausgefallen)
• Vergleich der Professionalisierung von Softwareentwicklung in Wirtschaft und Wissenschaft (Impulse von einer mittelgroßen Community-Plattform und einer großen Wirtschaftsprüfungsgesellschaft)
• Professionalisierung in der Entwicklung von Forschungssoftware jenseits der Digital Humanities an einem Beispiel aus der Geoinformatik

Durch die Impulse sollten Beispiele von Professionalisierung von RSEs gegeben werden. Zudem sollten Vergleiche gezogen werden zwischen der Professionalisierung von Softwareentwickler:innen in den Digital Humanities, in anderen Wissenschaftsbereichen (Geoinformatik) und der Wirtschaft, um die besondere Situation in den Geisteswissenschaften zu kontrastieren und neue Anregungen zu erhalten.

Durch einen Impuls aus der NFDI4Culture Cultural Research Data Academy (CRDA) war zudem eine Perspektive vertreten, die konkrete Weiterbildungsangebote vor allem im Bereich des Forschungsdatenmanagements im Blick hat und sich u. a. als Angebot der „Hilfe zur Selbsthilfe“ versteht, indem sie vorhandene Kursangebote inventarisiert und vermittelt sowie eigene Kurse anbietet.

Im Anschluss an jeden Impuls fand eine kurze Diskussion zu den angesprochenen Schwerpunkten statt. Darauf folgend wurden Themen für die weitere Diskussion aufgegriffen, um hieraus erste Skizzen für Handlungsmöglichkeiten zu entwickeln und zu formulieren.

Professionalisierung der Softwareentwicklung in den Digital Humanities, Geoinformatik und Wirtschaft im Vergleich

Die Impulse dieser Gruppe wurden von Personen vorgetragen, die sowohl in der Wirtschaft als auch in der Wissenschaft Erfahrung in der Softwareentwicklung haben. Durch ihre Impulse wurde deutlich, dass es Bereiche gibt, in denen die Unterschiede (vielleicht überraschend) gering ausfallen. Beispielsweise wird Dokumentation in der Wirtschaft dort besonders ausführlich angelegt, wo Risiken für finanzielle Verluste durch den Ausfall eines angebotenen Service gegeben sind. Allgemein fehlt die Zeit für angemessene Dokumentation aber genauso wie in der Wissenschaft. Auch die Code-Qualität wurde als Bereich genannt, in dem man sich vielleicht von dem Vorurteil befreien muss, dass die wissenschaftliche Softwareentwicklung generell „weniger professionell“ sei. Hier wurde darauf hingewiesen, dass der größte Unterschied darin bestehen könnte, dass der Code für viele Produkte wirtschaftlicher Softwareentwicklung schlicht nicht eingesehen werden kann und deshalb auch nur insofern „professionell“ sein muss, wie es für Kunden einen feststellbaren Unterschied macht.
 Aus den vergleichenden Impulsen ergaben sich aber auch eine Reihe von Themen, bei denen relevante Unterschiede festgestellt wurden. Besonders ergiebig waren hierbei die Diskussionen zu Anreizen zur weiteren Professionalisierung und zur professionellen Personalentwicklung sowie zu den Rollen und Rollenverteilung in Softwareprojekten.

Anreize & Personalentwicklung

An mehreren Punkten hat sich in den Impulsen wie in der Diskussion gezeigt, dass der Fokus auf die individuelle Professionalisierung dazu beiträgt, das schwer in seiner ganzen Komplexität zu fassende Thema besser handhabbar zu machen. Gleichzeitig ist festzustellen, dass man sich dabei immer wieder schnell auf institutionelle und organisatorische Aspekte verwiesen findet.

Das wurde zum Beispiel beim Thema „Mitarbeiter:innengespräche“ deutlich: In der Wirtschaft gibt es zahlreiche Verfahren, Hilfsmittel, Software und Methoden für die Mitarbeiter:innenentwicklung im Bereich der Softwareentwicklung. Es kann davon ausgegangen werden, dass sowohl von Seiten des Unternehmens als auch von Angestelltenseite ein großes Interesse an der weiteren Qualifikation der Mitarbeitenden besteht. Der Aufstieg auf höhere Seniority Level wird teilweise bis ins Detail zwischen Vorgesetzten und Mitarbeiter:in abgestimmt und geplant. Hier zeichnet sich also ein Teilbereich von Professionalisierung ab, der mit seinen konkreten Mitteln für die Softwareentwicklung in der Wissenschaft evaluiert werden kann. Es zeigt sich jedoch, dass sich dieses Modell nicht ohne Anpassung auf wissenschaftliche Softwareentwicklung übertragen lässt. Zum einen schon deshalb, weil Seniority Levels für Entwickler:innen in der Wissenschaft nicht existieren, während sie in der Wirtschaft Grundlage für Aufgaben, Verantwortung und Gehaltsklassen sind. Zwar steigt man im Öffentlichen Dienst in Erfahrungsstufen auf, jedoch unabhängig von Entwicklerskills. Und so fehlt hier der finanzielle und karrierebezogene Anreiz für Entwickler:innen, sich als solche weiterzuqualifizieren.
 Hier ist deutlich zu sehen, wie eng die individuelle Professionalisierung mit institutionellen und strukturellen Fragen verbunden ist. Gleichzeitig lässt sich durch den Vergleich aber auch die Aufgabe formulieren, dass es gilt, eine „Währung“ zu finden, die für RSE von Wert ist, wenn Anreize geschaffen werden sollen. Als ein Beispiel für eine solche Maßnahme kann hier die Gründung des CKIT Journals (https://journals.ub.uni-heidelberg.de/index.php/ckit/) genannt werden, in dem RSEs die im Wissenschaftsbetrieb etablierte Währung der Publikation durch das Schreiben von Reviews erwerben können.

Rollen in der Softwareentwicklung

Allgemein ließ sich feststellen, dass Rollen, die in der Wirtschaft im Normalfall auf verschiedene Personen aufgeteilt sind, in der Wissenschaft oft von nur einer oder wenigen Personen ausgefüllt werden müssen.

Die Rolle von Projektmanager:innen für die Softwareentwicklung muss in der Wissenschaft beispielsweise häufig von den Entwickler:innen selber übernommen werden. An DH Zentren wird das Projektmanagement auch von Personen der Leitungsebene oder erfahrenen Mitarbeiter:innen mitübernommen, kann aber nicht mit einer vergleichbaren Granularität erfolgen, wie in den Beispielen aus der Wirtschaft, da oft sehr viele Projekte gleichzeitig von denselben Personen gemanagt werden müssen. Das Projektmanagement kann in der Wissenschaft so zu einer zusätzlichen Aufgabe und Arbeitsbelastung für die Mitarbeiter:innen werden, während in den Beispielen aus der Wirtschaft das Projektmanagement als Entlastung erfahren wurde, die den Entwickler:innen „den Rücken freihält“, um sich auf die Programmierarbeit zu konzentrieren. Auch schien das Projektmanagement sich insofern zu unterscheiden, als in der Wissenschaft die Aufgaben lediglich in groben Zügen bestimmt wurden, während bei den Beispielen aus der Wirtschaft kleinteilig einzelne Arbeitsschritte inklusive des geschätzten Arbeitsaufwandes geplant und einerseits mit den Entwickler:innen, andererseits mit anderen Teilen des Unternehmens und mit Kund:innen abgestimmt wurde.

Nicht nur die Rolle der Projektmanager:in gehört oft zur Arbeit von RSEs. Auch (UI/UX) Designer:in, Front-End- und Back-End-Entwickler:in, Software Architects, DevOps u. a. werden in der Wissenschaft oft von ein und der selben Person übernommen. Das kann auf der einen Seite dazu führen, dass RSEs die Selbsteinschätzung annehmen „alles ein wenig und nichts so richtig“ zu können. Die Konzentration auf die Anforderungen nur einer Rolle kann entsprechend als Entlastung erfahren werden, insofern man eigene Erfolge besser „messen“ und entsprechend auch Bereiche, in denen man sich weiter professionalisieren will, besser identifizieren kann. Auf der anderen Seite kann die weniger spezialisierte Form von Entwicklungsarbeit durchaus auch attraktiv und zielführend sein, da ein Überblick über verschiedene Bereiche der Softwareentwicklung gegeben ist. Wichtig ist jedoch in jedem Fall, Bewusstsein und Transparenz für diese Sachverhalte herzustellen. Hierzu zählt, dass Entwickler:innen in Wirtschaft und Wissenschaft jeweils unterschiedlichen Arten von Druck ausgesetzt sind: In der Wirtschaft kann das Scheitern eines Projektes existentiell bedrohend für das Unternehmen und die an ihm hängenden Arbeitsplätze sein. Der Ausfall einer Software oder eines Service kann hohe Kosten verursachen. In der Wissenschaft ändern gute Leistungen und Skills nichts an der Befristung und permanent auslaufenden Verträgen. Außerdem ist das Risiko hoch, dass durch die Übernahme einer Vielzahl von Rollen, die (Selbst-)Einschätzung entsteht, dass man in allen Rollen nicht ausreichend professionell sei, was ebenfalls zu erheblichem Druck und Unzufriedenheit führen kann.

Unklarheit und Überforderung in Bezug auf Rollenerwartungen ist aber nicht der einzige Anlass für Unsicherheit in Bezug auf die eigene „Professionalität“ bei RSEs. In diesem Punkt wurde einhellig Handlungsbedarf festgestellt. Im Rahmen des Termins konnte zunächst eine Problemanalyse begonnen werden; es wurden verschiedene mögliche Grunde für die Unsicherheit von RSEs in Bezug auf die eigene Professionalität identifiziert.

Zum einen handelt es sich um einen relativ neuen und in weiten Teilen erst allmählich im Wissenschaftsbetrieb institutionalisierten Karriereweg, für den es noch wenig orientierende Vorbilder gibt.

Außerdem sind RSEs im Normalfall nicht als Software-Entwickler:innen eingestellt, sondern als wissenschaftliche Mitarbeiter:innen und die Erwartungen an erfolgreiche wissenschaftliche Arbeit (viele Publikationen und Zitationen, etc.), weichen von denen an erfolgreiche Softwareentwickler:innen ab (Publikationen von Software und Code-Beiträge zählen meist nicht als wissenschaftliche Beiträge). Die Aufgaben, sowohl auf dem Stand der Forschung als auch auf dem aktuellen Stand der relevanten technischen Entwicklungen zu bleiben, laufen parallel. Statt in einem Karriereweg zu konvergieren, laufen die Ansprüche an „gute Arbeit“ als Wissenschaftler:in und Entwickler:in meist auf Doppelanforderungen hinaus.

Auch liegt die Vermutung nahe, dass Zweifel an hinreichender Professionalität unter RSEs zusätzlich darin begründet sein könnten, dass sie meist nicht als Softwareentwickler:innen, sondern eben als Wissenschaftler:innen ausgebildet sind. Hier war es interessant zu erfahren, dass zwar auch in der Wirtschaft Software nicht in erster Linie von ausgebildeten Entwicklerinnen programmiert wird, dass dort deshalb aber weniger Unsicherheit besteht, ob es sich um professionelle Arbeit handelt. Im Wissenschaftssystem wird die Qualifikation fast ausschließlich an institutionalisierten Qualifikationsleistungen festgemacht; in der Wirtschaft wird bei Softwareentwickler:innen mehr auf die nachgewiesenen Skills, als auf den institutionellen Ausbildungsweg geschaut. Offen bleibt, in welcher Form sich eine so gesteuerte Selektion auf den Wissenschaftsbetrieb übertragen lässt und welche nicht intendierten Folgen sich hieraus ergeben (z. B. Abwertung der Arbeit von RSEs als nicht-wissenschaftliche Tätigkeit).

Fazit und Ausblick

Eine im Rahmen des Forums geäußerte Überlegung, universitätsübergreifend Fortbildungen für das Management von Projekten mit digitalen Komponenten anzubieten wurde zwar positiv gesehen, gleichzeitig aber wurde darauf hingewiesen, dass bei vergleichbaren Angeboten bereits die große Herausforderung bekannt ist, diese erfolgreich an die Zielgruppen heranzutragen und Anreize dafür zu geben, sie wahrzunehmen. Angebote für (auch überinstitutionelle) Schulungen scheinen durchaus vorhanden und zugänglich zu sein, die Teilnahme und Vereinbarkeit mit dem Arbeitsalltag der einzelnen Wissenschaftler:innen hingegen ist mit Hürden verbunden.

Ein Resultat der Arbeit des Forums war, dass durch die Herausarbeitung von Ähnlichkeiten und Unterschieden, Profile für die Arbeit von Softwareentwickler:innen in der Wirtschaft wie in der Wissenschaft schärfer und genauer umrissen werden können. Hierdurch kann festgestellt und dargelegt werden, was die Tätigkeit von Entwickler:innen in einem bestimmten Bereich zu bieten hat. Die Arbeit als Softwareentwickler:in in der Wissenschaft mag oft weniger fokussiert auf einen bestimmten Bereich sein, mit breiterer Verantwortlichkeit aber gerade mehr Abwechslung, und mehr Gestaltungsspielräume bieten. Die Bewusstmachung von Rollen und systembedingten Mechanismen, denen RSEs unterliegen, kann bereits für sich genommen dazu beitragen, den Grad der Professionalisierung zu verbessern, indem Softwareentwickler:innen in der Wissenschaft ihre Tätigkeit trotz vorhandener Unsicherheiten und Unklarheiten bereits als Profession verstehen und diese selbstbewusster und erfolgreich vertreten können.

Einen Beitrag zu professionellerem Erwartungsmanagement vermag auch die Verbesserung des Angebots von Praktika in DH Projekten zu leisten, die im Forum als wichtiger Baustein erkannt wurde. Auch Praktika in der Wirtschaft könnten für RSEs sehr lohnenswert sein. Die Frage, inwieweit auf das Praktikumsangebot in der Wirtschaft Einfluss genommen werden kann, konnte im Forum jedoch nicht hinreichend beantwortet werden.

Um die Postion von RSEs auf individueller Ebene zu verbessern, wurden als konkrete Handlungsmöglichkeiten beispielsweise der verstärkte Kontakt zu Förderern (um auch dort das Bewusstsein für dringend benötigte Karrierewege weiter zu schärfen) und eine engere Zusammenarbeit mit der Cultural Research Data Academy (zur Förderung von Code Literacy und allgemeiner Stärkung des Bereichs Forschungssoftware im Angebotsportfolio) erkannt. Weitere Angebote sollen durch die Task Area Research Tools & Data Services erarbeitet und vom Forum evaluiert werden.