Lange schon finde ich die Reihe “Ten simple rules for …” des Journals “PLOS COMPUTATIONAL BIOLOGY” amüsant. Ich lese sie gerne und ab und an gibt es Anregung zum Nachdenken – keineswegs sollte man annehmen, dass mit zehn einfachen Regeln ein beliebiges Thema allumfassend behandelt werden kann. Und so ist es auch nicht sinnvoll sich aufzuregen oder unbedingt in jedem dieser Artikel eine gute Anleitung finden zu wollen.
Es gibt aber zwei Artikel, die in der letzten Zeit meine besondere Aufmerksamkeit erregt haben, weil sie unmittelbar meinen Beruf treffen. Ich sitze als Lebenswissenschaftler auf einer Position zwischen den Stühlen – oder positiv ausgedrückt in einer Vermittlerrolle:
- BiologInnen beraten, die bei “uns” (also einer Gruppe, die einen Großrechner betreibt) ihre Daten analysieren wollen
- BiologInnen (sanft) den Kopf zurecht rücken, wenn diese mal wieder sehr eigene Vorstellungen haben, wie ein Großrechner zu funktionieren hat
- BiologInnen gegenüber den Vorstellungen der Kollegen zu verteidigen, die sehr eigene Vorstellungen davon haben, wie Biologie als Wissenschaft und Bioinformatik im Speziellen zu funktionieren hat.
Und so sind die zwei Artikel, die ich kommentieren möchte:
- Ten simple rules for biologists initiating a collaboration with computer scientists und
- einen Artikel, der die “andere Seite” beleuchtet: Ten simple rules for providing effective bioinformatics research support
Heute geht es um den ersten Artikel von Monika Cechova (hiernach kurz: “die Autorin“) vom Central European Institute of Technology (CEITEC) in Brno (ehemals Brünn) in der Tschechischen Republik. Die Autorin will diejenigen ansprechen, die als BiologInnen eine Kooperation mit einer Informatikgruppe suchen. Insofern denke ich natürlich diesen Aspekt – muss aber auch einen weiteren Aspekt hinzudenken: In meiner Welt gibt es nicht allein “wissenschaftliche Kooperationen in der Informatiker Code für die BiologInnen schreiben”, sondern ein breites Spektrum, von “wir wollen auf dem Großrechner rechnen” über “wir brauchen dabei Unterstützung und entwickeln gemeinsam einen Workflow” bis zu “wir brauchen eine spezielle Anwendung, die jemand für uns entwickeln muss”. Daneben gibt es nicht die “BiologInnen”, sondern “BiologInnen, die überhaupt kein bisschen skripten können” über Leute, die “Angewandte Bioinformatik studiert haben” (und deren Programmierkenntnisse in Mainz oftmals mau sind), bis zu BioinformatikerInnen, die fast schon bessere ProgrammiererInnen sind als die üblichen InformatikerInnen. (Bei all dem soll das in meinem Fall auch “clustertauglich” werden, aber dazu ein anderes Mal mehr.)
Ich gehe hier einfach mal nach den Überschriften der Original-zehn-Punkte-Idee und kommentiere frei Schnauze:
Rule 1: Do not try to turn them into biologists
Was die Autorin meint, ist dass InformatikerInnen i.d.R. wenig Verständnis von Biologie haben – das trifft auf mich, wie ich finde nicht zu. Aber ja, eine Einführung in die jeweilige Fragestellung kann sehr wertvoll sein, wenn man eine optimale Hilfestellung erwartet. Umgekehrt, wenn Leute die besseren (Bio-)InformatikerInnen sein wollen, wird aber doch ein Schuh draus:
In der Tat ist es manchmal witzig wenn man mich für einen “artfremden” Informatiker hält. Da kann es auch schon mal vorkommen, dass mir ein Mediziner (“-er”, denn bei Frauen habe ich das noch nicht erlebt) im Brustton der Überzeugung erzählt, dass ein short-read Alignment Programm X dasjenige sei, dass die Community als das Beste™ befinde und ob ich dies nicht wüsste?!?? Nein, ich wusste zu diesem Zeitpunkt nicht nur dies nicht, sondern hatte gerade am Vortag eine Vergleichsveröffentlichung zu dieser Art Software gelesen und bot bereits Unterstützung für viele dieser Programme an – nur nicht für sein Lieblingsprogramm (war aber offen dafür das auch noch installieren, denn: Warum nicht?). Nachdem ich aber nicht willens war die Prämisse des “X ist das beste Programm” anzuerkennen, sondern vorsichtig zu bedenken gab, dass ich erst die genaue Anwendung kennen müsse, um ein Urteil zu treffen oder gar eine (hier augenscheinlich überflüssige) Empfehlung auszusprechen, war die Sache gelaufen: Der potentielle Nutzer wollte lieber anderswo rechnen.
Das ist völlig absurd (und wer wissen möchte warum, werfe einen Blick auf die Wikipedia-Sektion zu short-read Alignment Programmen) und fraglos die Spitze des Eisbergs. Häufiger kommt es vor, dass mir Leute erklären wollen, wie aus ihrer Sicht Bioinformatik zu funktionieren hat, die keine Ahnung haben, wie ein Großrechner funktioniert, aber gut … da fängt mein Job an.
Rule 2: Do not judge knowledge gaps
Jau, als einziger in meiner Gruppe, der sich mit diesen Dingen befasst, kann ich nicht an Dritte verweisen. Und selber Alles wissen? Natürlich nicht. Die Hintergründe kennt die “andere Seite” natürlich nicht immer. Aber fleißige rupture de caténaire-LeserInnen wissen: Bioinformatik ist nicht einfach “nur” genom-orientiere Bioinformatik, sondern bewegt sich auch an den Grenzen von Chemie und Physik. Sie deckt Strukturbiologie ebenso ab wie Molecular Screening, dreht sich manchmal um Agentenbasierte Modellierung und beinhaltet immer häufiger künstliche Intelligenz.
Von all diesen Gebieten habe ich mindestens schon gehört. In manchen kenne ich mich gut aus, manchmal sogar sehr gut. Aber selbst in den Gebieten in denen ich mich richtig gut auskenne, habe ich auch immer wieder Wissenslücken (wer ist schon perfekt?). Das aufs Brot geschmiert zu bekommen ist in der Tat nicht zielführend..
Die Autorin meint natürlich etwas Anderes: Dass BiologInnen davon absehen sollen auf Computer-Leute hinab zu schauen, wenn diese bestimmte Bio-Fakten nicht parat haben. Das finde ich auch einen guten Punkt – und gilt ebenso umgekehrt. Also: Allein die Bioinformatik ist derartig komplex, dass es für einzelne BioinformatikerInnen unmöglich ist auf alle Fragen ad hoc eine gute Antwort zu wissen oder gar bei jeder Entwicklung auf Höhe der Zeit zu sein.
Rule 3: Learn how computers store data and format information in a computationally friendly way
Oooh, ja. Das wäre gut. Anderseits gibt es dafür Kurse – auch anderswo, nicht nur bei uns. Muss man sich nicht im Bio-Studium drauf schaffen. Und wer einen Bioinformatik-Schwerpunkt im Studium hat, sollte das wissen und muss sich auch nicht mehr damit befassen – ist also ein wichtiger Punkt, aber nichts womit man sich zu lange den Kopf zerbrechen sollte.
Rule 4: Describe your data in a way that facilitates collaboration
Kein Kommentar an dieser Stelle. Spricht eigentlich für sich selbst. Doch halt:
- schreibt die Autorin über das gute Würzen mit deskriptiven Metadaten – das ist verdammt wichtig und
- über Tabellen. Na, da kann ich – weiter unten – mir doch einen Seitenhieb nicht verkneifen.
Das eigentliche Datenmanagement kommt hier völlig zu kurz. Darauf wird der nächste Artikel eingehen und ich auch in ein paar Tagen.
Rule 5: Learn if you should speed up your code (and how)
Nee. Wirklich nicht. Dafür wird ja eine Zusammenarbeit gesucht. Im Gegenteil: Das der meiste Bioinformatikcode grausam schlecht ist, war hier im Blog schon ein paar Mal Thema. Es braucht nicht noch mal Leute, die der Auffassung sind, das weil jeder programmieren kann (was irgendwie wahr ist), es auch jede(r) tun muss.
As a biologist, you probably also heard that some programming languages are faster than others. However, in day-to-day science, I strongly believe that readability and reproducibility come before speed. Other scientists might be more comfortable reusing your high-level Python code compared to a faster low-level C code. Note that here, I am not talking about software that will be run thousands of times, potentially by as many users. I am referring to code that accompanies your research findings, which will more likely than not be a combination of established pipelines and custom scripts. Therefore, do not engage in a collaboration with the aim of speed up without a careful thought.
Da hat die Autorin schon recht, will ich gar nicht in Abrede stellen. AaaaBER: Was ich hervorgehoben habe, trifft halt auf die guten Programme schon zu. Die werden nämlich tausende Male durch sehr viele Nutzer aufgerufen. Und da spielt Effizienz hoffentlich schon eine Rolle. Wenn ihr BiologInnen seid, überlegt mal wie viel Zeit da verschwendet wird und wie viel CO2 unnötig in die Luft geblasen wird, wenn die Programme / Skripte unnötig lahm sind. Wenn ihr SteuerzahlerInnen seid, überlegt mal wie viel Geld Computerinfrastruktur für Forschung kostet (viele Millionen Euro) und wie viel davon verschwendet ist, wenn die Ressourcen nicht gut ausgelastet sind (was man auf verschiedene Weise erreichen kann): Mindestens hundertausende Euro bezogen auf das Bundesgebiet, allein durch den schlechten Zustand der Bioinformatik – und das ist übervorsichtig geschätzt, wie ich finde.
Rule 6: Think about concepts and the audience, not the programming language
Das gilt immer und überall – was nicht heißt, dass es einfach ist. Die Autorin hat ein wenig Anderes geschrieben, aber ich finde, die Überschrift von Regel 6 bereits vielsagend und sie darf für sich stehen.
Rule 7: Aim for transparency and reproducibility, share your code at every stage
Jau, wenig ist schlimmer, als Skriptsammlungen, die irgendwer irgendwo verbrochen hat: Im letzten Jahr habe ich mal einen Gastvortrag in einem Computerpraktikum bei GenetikerInnen gehalten. Ich war zu früh dran und habe mitbekommen, wie sie ein unversioniertes Perlscript, dass sie auf einer Seite eines Museums (nein, wirklich!) gefunden und heruntergeladen hatten. Das sollte die Beispieldaten konvertieren und hat bei keinem der Studis funktioniert.
Normal ist wenn irgendjemand selbstgeschriebenen Code irgendwo rumfliegen hat, irgendwann Hilfe sucht und man dann, statt sich durch den Wust zu quälen, alles neu schreibt (nicht selten in einem Bruchteil der Zeilen und wesentlich schnellerem Code). Das so keine Reproduzierbarkeit erreicht werden kann, sollte mittlerweile klar sein – oder muss man noch Überzeugungsarbeit leisten?
Rule 8: Understand strengths and limitations of each discipline
Der Autorin geht es hier um die verschiedenen Kulturen in den verschiedenen Fächern und wie diese die Herangehensweise in Projekten beeinflussen. Sehr lesenswerter Abschnitt!
Rule 9: Communicate how the results of your collaboration will be validated
Schließt unmittelbar an den Abschnitt über die Kulturunterschiede an:
Just like writing is an iterative process of improvement, so is the joint project development with a computer scientist. In each iteration, the pipeline is refined until the satisfactory output is achieved and, hopefully, reproducible. Initially, biologists might not even be able to fully define the parameters of the pipeline they are requesting but will guide their decisions based on the data. Other times, the intermediate results will need to be validated, which will take time and effort. Rarely will an initial pipeline suffice for all the future applications, so the long-term collaboration is favorable.
…
Finally, because pipelines can be improved indefinitely, emphasizing the back-and-forth nature of the progress, communicating the characteristics of the final product, and discussing the types of validation that will be performed are all good ways to set initial expectations.
Das können sich alle im Feld merken – schließlich ist wenig mehr frustrierend, wenn über Ziel und Zwischenschritte unzureichende Verabredungen bestehen. Am Ende sind sonst alle unzufrieden.
Rule 10: Do not get involved in wars over what the “real” science is
Das gilt zwischen allen möglichen Fachkombinationen: Akademische Hybris hat keiner Interdisziplinären Arbeit je gut getan. Wenn man ein anderes Fach und den dortigen Wissenschaftsanspruch nicht versteht: Dran bleiben, sich erklären lassen. Eine gute Freundin, Jura-Professorin, “nerve” ich seit Jahren mit der Frage was die Wissenschaft in ihrer Forschung beinhaltet. Ich habe viel dazu gelernt!
Rule 11: Do not use Excel
Diese Regel ist nicht Teil des Artikels, sondern “geklaut” aus der Kommentarleiste zum Artikel – wer hier mit liest, wird nicht erwarten, dass ich den Kommentaroren widerspreche, sondern eher der Autorin in Bezug auf Regel 4: Denn wer darauf beharrt wissenschaftliche, tabellarische Daten in Tabellenverarbeitungsprogramme wie Excel oder LibreOffice zu stecken, hat nicht gehört, dass es vielfach Probleme gegeben hat, sondern beharrt darauf Verarbeitung manuell, unprotokolliert durch zu führen und somit nicht nachvollziehbar zu belassen.
Rule 12: Talk to the one(s) who have to do the work
Diese Regel steht so auch nicht im Artikel – es ist meine eigene. Wenn ihr als BiologInnen eine bioinformatische Auswertung eurer Daten plant und klar ist, dass ihr Hilfe benötigen werdet, redet frühzeitig – möglichst vor Erhebung der Daten – mit denjenigen, die euch helfen können. Und zwar nicht nur einmal, sondern während einer Phase der Zusammenarbeit möglichst in einem festen Turnus immer wieder. Das ist gut investierte Zeit: Nur so können Erwartungen der beiden Parteien angepasst und unnötige Enttäuschung vermieden werden. Nur so können Missverständnisse, die es unweigerlich geben wird, ausgeräumt werden und Fehler, die deshalb gemacht wurden, ausgeglichen werden.
Redet mit denjenigen, die die Arbeit machen. Nicht nur mit ihren Chefs bei der Besprechung bei der das Projekt vereinbart wird und alle übereinstimmen, denn “everything is easy for the man who doesn’t have to do the work” wie ein Freund mal meinte.
Letzte Kommentare