Ich werde es versuchen. Dies ist hauptsächlich meine persönliche Ansicht, die auf meiner Verwendung und Implementierung von akademischer Software basiert. Wie viele der bereits erwähnten Kommentare glaube ich nicht, dass schlechte Software spezifisch oder sogar häufiger im akademischen Bereich ist. Ich denke jedoch, dass es einige Gründe gibt, die für das jeweilige Gebiet spezifisch sind.

Software hat keine Priorität

In der Wissenschaft dreht sich bei den wichtigsten Leistungsindikatoren alles um Papier Veröffentlichungen. Software ist zwar meiner Meinung nach sehr nützlich, hat aber nur einen sehr geringen Wert. In den meisten Fällen handelt es sich bei Software-Implementierungen um Nebeneffekte oder Proof-of-Concepts, die bestenfalls dazu dienen, die Anzahl der Zitate zu erhöhen (natürlich gibt es Ausnahmen).

Als Softwareentwickler sind Sie sich sicher bewusst das Wissen, die Zeit und den Aufwand, die für die Erstellung hochwertiger Software erforderlich sind. Angesichts des Mantras veröffentlichen oder zugrunde gehen in der Wissenschaft wird diese Zeit häufig für das Schreiben einer neuen Veröffentlichung aufgewendet. Es ist eine Risiko-Ertrags-Überlegung.

Mein persönlicher Standpunkt ist, dass Qualitätssoftware sehr wichtig ist. Beispielsweise besteht der erste Schritt beim Vergleichen eines neuen Algorithmus mit dem vorherigen Stand der Technik häufig darin, den Stand der Technik aufgrund mangelnder Implementierung erneut zu implementieren. Dies führt offensichtlich zu einer Zeitverzögerung und kann eine Reihe von Fehlern verursachen. Trotzdem denke ich, dass sich im Allgemeinen wenig ändern wird, bis Software irgendwie durch Leistungsindikatoren bewertet wird.

Forscher sind keine Programmierer

Die meisten Forscher haben wenig oder keine Programmiererfahrung, obwohl YMMV davon abhängt das Feld. Ich denke, es ist fair zu sagen, dass die Mehrheit der Forscher gelernt hat, selbst zu programmieren, wenn sie mit Problemen konfrontiert werden, wo sie sie brauchen. Das oberflächliche Erlernen einer Sprache ist normalerweise nicht das Problem, aber Sie benötigen mehr als nur oberflächliches Wissen, um hochwertige Software zu erstellen (Auswahl von Datenstrukturen, Entwurfsmustern, fundierte Sprachkenntnisse, ...). Dies ist eine Hürde für autodidaktische Programmierer ohne Informatik-Hintergrund.

Ein weiteres Problem, mit dem weniger erfahrene Programmierer konfrontiert sind, besteht darin, nicht zu erkennen, wann ein Refactoring erforderlich ist. Sie können unzählige Teile schlecht strukturierter Software finden. In der Forschung ist dies eine natürliche Folge der iterativen Implementierung beim Entwerfen eines Algorithmus, der sich zu einer monströsen Software voller Hacks entwickelt. Das Monster könnte trotzdem tun, was es wollte, wenn Sie genau wissen, wie man es nett fragt. Für viele Forscher endet hier die Geschichte: Holen Sie sich die Ergebnisse und legen Sie das Biest für immer weg. Das Waschen des Monsters erfordert oft eine ernsthafte Zeitinvestition, bevor es für einen Spaziergang in der Öffentlichkeit ausgesprochen wird. Das lohnt sich nicht immer.

Trends beim maschinellen Lernen

Mein Fachgebiet ist maschinelles Lernen, in dem Software zunehmend geschätzt wird. Beispiele für diesen Trend sind ein wachsendes Software-Repository und ein Positionspapier einiger großer Namen auf dem Gebiet. Ich bin sehr zufrieden mit dieser Entwicklung, da Qualitätssoftware es dem gesamten Gebiet ermöglicht, schneller voranzukommen und die Reproduzierbarkeit zu erhöhen.

Ein aktueller Patch für das Problem besteht darin, Artikel über von Experten überprüfte Softwareimplementierungen veröffentlichen zu können. Ich weiß, dass dies in maschinellem Lernen und Statistiken möglich ist. Solche Software ist normalerweise von höherer Qualität.

Zusätzlich zu der Antwort von @ MarcClaesen möchte ich den Standpunkt eines Chemikers hinzufügen.

• Ich bin ein programmieraffiner Chemiker. Nach meiner Erfahrung ist das eine seltene Art. Vielleicht weniger selten auf diesen Seiten. Obwohl vielleicht nicht seltener als ein Informatiker in einem Chemielabor, der gute Laborpraxis anwendet ...

• Ein wichtiger Punkt, den Sie beachten sollten, ist, dass Studenten (zumindest Chemiker) haben während ihres Studiums überhaupt keine Einführung in die Computerprogrammierung . Möglicherweise müssen sie eine Einführung in die Verwendung von Tabellenkalkulationsprogrammen und die Suche in Literaturdatenbanken erhalten, aber das war's.
  Ich treffe Studenten, die ihr Forschungspraktikum und ihre Abschlussarbeiten in einem Teilgebiet machen, das sich mit Datenanalyse befasst. Es ist äußerst selten, einen Studenten zu treffen, der bereits Programmiererfahrung gesammelt hat, obwohl diese Spezialisierung mathematikaffine Studenten "konzentriert". Ich bin immer noch auf der Suche nach guten Kursen an der Universität, an die ich sie senden kann, um eine Einführung in die Programmierung zu erhalten.
  Ich mag das Software Carpentry -Konzept. Beachten Sie jedoch, dass es auch keine Einführung in die Ideen und Denkweisen der Programmierung gibt. Ebenso beginnen die mir bekannten Einführungsmaterialien nicht wirklich dort, wo die Schüler anfangen müssten.
  (Ich habe nach guten Einführungen gesucht, weil ich mich nur schwer daran erinnern kann, wie die Welt aussah, bevor ich als Teenager mit dem Programmieren begann .)

• Die meisten Nicht-CS-Wissenschaftler, die ich kenne, haben das Programmieren autodidaktisch gelernt und schwimmen oder ertrinken . Beachten Sie, dass die meisten Naturwissenschaftler eine Denkweise haben, die eine Programmiersprache erforscht, genau wie sie das Verhalten unbekannter Substanzen oder Instrumente erforscht . Da Programmiersprachen deterministisch sind, ist es vergleichsweise einfach, auf diese Weise genug Verständnis zu erlangen, um ein Skript zusammenzustellen, um etwas zu berechnen. (Ich erinnere mich an einen Kollegen, der während seiner Diplomarbeit seinen ersten Kontakt mit der Programmiersprache in Matlab hatte. Einige Jahre später "erfand" er das Funktionskonzept.) Während Ihrer Abschlussarbeit haben Sie jedoch keine Zeit, gute Programmierpraxis zu erlernen , auch wenn Sie möchten. Und danach wird von Ihnen erwartet, dass Sie arbeiten und Ergebnisse erzielen. Das Erlernen von Programmiersprachen ist nicht unmöglich, liegt jedoch normalerweise außerhalb des erwarteten Rahmens Ihrer Tätigkeit. Der erwartete Umfang besteht normalerweise darin, dass Sie sich gerade so gut auskennen, dass Sie einige Berechnungen durchführen können.

• Ein damit verbundenes praktisches Problem ist, dass keine professionellen Programmierer zur Verfügung stehen, daher keine gute Programmierpraxis für die Schüler . Ich denke, dies ist immer noch ein blinder Fleck in der Organisation von Arbeitsgruppen. Keine der Gruppen, in denen ich bisher gearbeitet habe, hatte einen professionellen Programmierer. Einige Gruppen waren objektiv zu klein, um sich eine leisten zu können (zumindest nicht, wenn dieser Programmierer nicht auch im Chemie- / Spektroskopielabor gut gewesen wäre ... - das zu finden ist noch schwieriger als einen Chemiker zu finden, der einige Grundlagen guter Programmierpraxis gelernt hat ).

• Die meisten der mir bekannten "Monster" -Programme begannen ihr Leben als winziges kleines Skript von jemandem, der gerade genug Programmieren gelernt hatte, um die ersten nützlichen Zeilen seines Lebens zusammenzustellen. Während der nächsten 2-3 Jahre (üblicher Rahmen: Doktorandenstudium) wächst dies stetig und die Zeit wird es immer nur erlauben, genau das zu ändern, was gerade gebraucht wird. Da die Leute nett sind, geben sie das Monster an andere Leute weiter, die noch weniger Programmierer sind. An dem Punkt, an dem man sagen würde, dass es genügend Erfahrung gibt , um zurückzutreten und eine gründliche Umgestaltung basierend auf den gesammelten Erfahrungen durchzuführen, wird die Promotion verteidigt Der Schüler wechselt normalerweise zu einer völlig anderen Arbeit und das Programmierprojekt wird abgebrochen .

• Als Wissenschaftler muss ich sagen, dass die Softwareentwicklungsprozesse, auf die Sie sich beziehen, für einen Großteil der wissenschaftlichen Programmierung, die ich mache, nicht sehr gut anwendbar sind : Sie setzen voraus, dass Sie bereits eine Vorstellung davon haben, wie das Problem gelöst werden kann (Wie erstellen Sie ein Ergebnis [oder entwerfen Ihre Architektur], wenn Sie keine Ahnung haben, wie es funktionieren könnte?). Oft ist nicht einmal das Ergebnis bekannt.
  Aus Sicht der Grundlagenforschung haben Sie das Ende der Grundlagenforschung erreicht, wenn Sie wissen, wie es funktioniert. Dann beginnt die angewandte Entwicklung, und dort sehe ich, wie die Softwareentwicklungsprozesse angewendet werden können, aber dies liegt per Definition außerhalb des Rahmens für Grundlagenforschungsprojekte.
  Der Teil der Grundlagenforschung, OTOH, kann als Versuch und Forschung bezeichnet werden - Fehler bei der Erstellung des ersten bloßen Blicks auf ein Ergebnis.
  Möglicherweise sehen Sie nur die Spitze des Eisbergs des wissenschaftlichen Codes, an der es gerechtfertigt gewesen wäre, ordnungsgemäß dokumentierten Code mit einer definierten Schnittstelle usw. zu schreiben (andere bewährte Verfahren wie Unit-Tests würde ich lieber schon bei sehr frühen Versuchen sehen ...): Möglicherweise sehen Sie nicht die riesigen Mengen an Code, die für Forschungsideen produziert werden, die sich dann als nicht so gut herausstellen und aufgegeben werden.

• Es gibt einen großen Unterschied in der Verwendungsperspektive zwischen den meisten wissenschaftlichen Programmen, die ich sehe, und einem traditionellen Softwareprojekt . Der größte Teil dieser Programmierung erfolgt in Master- oder Doktorarbeiten. Der Umfang des Ganzen ist eher begrenzt. In der Regel handelt es sich um ein Ein-Personen-Projekt, da eine Abschlussarbeit per Definition ein Ein-Personen-Projekt ist. Für den Einzelentwickler beträgt der Umfang der möglichen Verwendung der Software höchstens einige Jahre oder dieses eine Projekt, und normalerweise wird auch nur dieser eine Entwickler der einzige Benutzer sein. Dies unterscheidet sich grundlegend von der "normalen" Softwareentwicklung. Die gegensätzliche Perspektive der Grundlagenforschung ist, dass selbst wenn die Methode weit verbreitet sein sollte und sich nicht herausstellt, dass die Idee nur für das eine Problem funktioniert hat, für das sie erfunden wurde, das nächste, was passiert, ist, dass möglicherweise jemand den Algorithmus verbessert Normalerweise führt dies zu einer völlig anderen Implementierung. Oder finden Sie heraus, dass es in ein viel allgemeineres Framework passt, das einer völlig anderen Schnittstelle usw. entspricht. In dieser Situation ist es nicht einmal sicher, ob sich das sorgfältige Entwerfen einer Schnittstelle für die Methode überhaupt auszahlt.
  I. Ich sage nicht, dass dies mit einer lesbaren Implementierung nicht möglich oder nicht möglich wäre. Es ist jedoch nicht die Situation, die dazu anregt, das Schreiben von lesbarem Code zu erlernen.

• Ein großer Teil meiner Programmierung besteht darin, Datenanalysen zu erstellen, die auf ein bestimmtes Experiment zugeschnitten sind . Pragmatisch gesehen verallgemeinere ich den Code nur dann in wiederverwendbare Pakete, wenn ich entweder von Anfang an weiß, dass ich ihn wieder benötige, oder wenn ich tatsächlich auf diese Situation stoße. Dies ist jedoch erstaunlich selten im Vergleich zu z. Was ich als Student als "normaler" Entwickler einer Datenbankanwendung erlebt habe. Dies ist jedoch teilweise wahrscheinlich darauf zurückzuführen, dass ich für einige Projekte, bei denen ich weiß, dass Code wiederverwendet wird, von Anfang an ein Paket / eine Bibliothek eingerichtet habe, das ich parallel zu den vorliegenden Datenanalysen entwickle. Aber dann unterscheidet sich meine Sichtweise völlig von der des Studentenbereichs, da ich davon ausgehe, dass ich diese Codebasis jahrelang weiter verwenden werde.

• Eine der schönsten und erstaunlichsten (völlig unerwarteten) Erfahrungen. Die wissenschaftliche Programmierung, die ich gemacht habe, war: Ich habe ein Papier eingereicht und die Software-Implementierung parallel veröffentlicht. Einer der Prüfer fragte, wie ich sicherstellen könne, dass die Berechnungen korrekt sind. Dadurch konnte ich antworten, dass ich Komponententests verwende, und das Paket enthält tatsächlich etwa doppelt so viel Code für die Tests als für Berechnungen. Dies war unerwartet, da es in meinem Bereich bereits ziemlich ungewöhnlich ist, den Code mit dem Papier freizugeben - aber ich hatte noch kein Papier gesehen, in dem erklärt wurde, welche automatischen Tests für die Implementierung bereitgestellt werden -, sodass ich nicht erwartet hatte, dass diese Informationen es schaffen könnten in die eigentliche Zeitung.
  Ich nehme das als äußerst vielversprechendes Zeichen!

• Ein weiteres vielversprechendes Zeichen ist, dass, wenn ich meinen Mitarbeitern * das Konzept der Versionskontrollsysteme erkläre, viele die Idee mögen und sie als etwas beschreiben, von dem sie dachten, dass es existieren sollte, aber nicht bekannt existiert tatsächlich außerhalb des Bereichs der Word-Änderungsverfolgung. (Obwohl ich für den Forschungsworkflow immer noch denke, dass das mir bekannte VCS (svn, git) genauso gut funktioniert wie für reine Codierungsprojekte.)
  Update einige Jahre später: Nicht-Programmierer-Kollegen dazu zu bringen, die Versionskontrolle zu verwenden, ist immer noch eine sehr schwierige Diskussion (auch weil sich der Umgang mit VCS mit Binärdateien nicht so schnell verbessert hat, wie ich es mir erhofft hatte). Ich bin meistens einen Schritt zurückgegangen und wir verwenden nextcloud jetzt zum Teilen von Daten. Dies bietet zwar keine echte Versionskontrolle, erleichtert aber zumindest allen, die über den gleichen Status der Daten / Dateien sprechen.

* auch diejenigen, die überhaupt nicht programmieren, die die gemessenen Daten in das System einspeisen oder die z die medizinisch / biologische Interpretation.

---

Update: Aufgrund der Erfahrungen, die ich seit dem ersten Schreiben dieser Antwort gesammelt habe, habe ich die organisatorischen Aspekte jetzt viel weiter ausgeführt:

Ich habe die akademische Welt größtenteils verlassen, bin jetzt freiberuflich tätig, habe aber noch Forschungsprojekte, bei denen ich als Subunternehmer für (akademische) Forschungseinrichtungen tätig bin. Für ein bestimmtes Vorverarbeitungsverfahren, das ich liefern musste, wurde ich pauschal abgelehnt, für "unnötige Dinge" wie Komponententests und die Kapselung des Arbeitscodes in einer Bibliothek / einem Paket mit einem eigenen Namespace zu bezahlen. Die Methode ist ein Datenanalyseverfahren, daher sind Fehler in der Programmierlogik die wichtigste Art von Fehlern (gegen die Unit-Tests ein bestimmtes Maß an Schutz bieten können). Es ist in R zu verwenden, dh in interaktiven Arbeitsszenarien, bei denen ein hohes Risiko besteht, dass der Arbeitsbereich des Benutzers durcheinander gebracht wird, wenn die Funktionen von Drittanbietern nicht in einem eigenen Namespace enthalten sind.
Diese Ablehnung kam von der oberen Führungsebene der Forschung Institut.

@gerrit kommentiert, dass die Universitätsbürokratie einer Gruppe möglicherweise nicht erlaubt, einen professionellen Programmierer zu haben. Ich denke, dies ist wahrscheinlich eine alltägliche Realität. Ich denke jedoch auch, dass dies mit dieser organisatorischen Blindheit zusammenhängt, von der ich hier spreche. Wenn das obere Management im akademischen Bereich die Bedeutung des Einsatzes modernster Arbeitstechniken bei der Datenverarbeitung und Softwareentwicklung erkennen würde, würde die Universitätsverwaltung dies wahrscheinlich auch anders sehen. Und wenn Zuschussvorschläge professionelle Daten- und Software-Management-Themen enthalten würden, würden sich die Dinge möglicherweise auch auf dieser Ebene verbessern. Ich denke, die Wissenschaft befindet sich hier in einem Teufelskreis: Alle außer den Studenten gelten als sehr teuer, sodass Projektvorschläge es nicht wagen, "technisches" Personal einzubeziehen. Wenn das Thema Datenmanagement oder Softwareentwicklung angesprochen wurde, hat unser akademisches Management nie darüber nachgedacht, ob "wir einen CS-Doktoranden haben könnten", was nicht gut passt: Die Projekte benötigen eher gut etablierte und zuverlässige Arbeitsansätze als Alles, was als ausreichend neu angesehen wird, um als CS-Forschung zu gelten, damit der Student promovieren kann.
Und natürlich kann das obere Management von seinen Kollegen oder von Beispielen davon überzeugt werden, wie viel professionelle Behandlung dieser Aspekte hilft, aber Solange sie nicht überzeugt sind, wird es äußerst schwierig sein, Geld und die Erlaubnis zu finden, um herauszufinden, ob und wie viel es hilft.

Es gibt einige großartige Antworten, und ich möchte meine zwei Cent in dieses Thema einbringen, da es sich um ein sehr relevantes Thema handelt, über das ich oft nachdenke oder das ich mit meinen Kollegen diskutiere. Es wird unvermeidlich einige Überschneidungen mit Teilen bestehender Antworten geben. Ich hoffe nur, dass ich in diesen Fällen eine etwas andere Perspektive geben kann.

Ich habe als Hauptfach angewandte Mathematik gemacht und meine Master in gemacht biologische medizinische Modellierung von & (was auch immer das bedeutet). Ich habe mein Doktoratsstudium in Bioinformatik und Systembiologie abgeschlossen. Ich arbeite fast ausschließlich in silico und habe viele dieser monströsen, hässlichen und traurigen Software-Teile gezeugt.

Zunächst einmal denke ich, dass Sie einen kleinen, aber wichtigen Fehler bei der Formulierung Ihrer Frage machen. Sie sagen:

" Warum schreiben viele talentierte Wissenschaftler schreckliche Software?

Ich würde stattdessen

" Warum ist von talentierten Wissenschaftlern geschriebene Software schrecklich?

"

Der Unterschied ist subtil, aber für den Rest meiner Antwort wesentlich . Schließlich ist es nicht so, dass sich Wissenschaftler an einem Tisch versammeln und beschließen, schreckliche Software zu schreiben.

Viele Wissenschaftler, die Code schreiben, sind nicht dazu ausgebildet, dort Software zu schreiben.

ist ein schwerwiegender Unterschied zwischen dem Wissen, wie man Code und dem Wissen, wie man Software schreibt. Ich habe während meines Studiums und meines Masterstudiums fast so viele Kurse in der CS-Abteilung absolviert wie in Mathematik, daher fühlte ich mich mit meinen Programmierkenntnissen ziemlich sicher. Bis ich mit Fragen wie Verpackung, Abhängigkeitsmanagement, Lebenszyklen, Lizenzierung usw. konfrontiert wurde. Keines davon war während meines Studiums im Lehrplan enthalten. Ich weiß nicht, ob diejenigen, die CS als Studenten machen, diese Konzepte lernen, aber ich musste es verdammt noch mal nie, bis ich sie plötzlich kennen musste.

Chefs / Vorgesetzte vieler Wissenschaftler, die Code schreiben, sind nicht im Schreiben von Software

Sie müssen nicht nur eine Menge neuer Dinge lernen, sondern sich auch vorstellen, dass Sie nicht erklären können, warum dies wichtig ist, damit Sie Ihrem Chef diese Dinge lernen. Ich habe dieses Problem ziemlich oft, da das Schreiben von Code oft mit Laborarbeiten in unserer Abteilung vergleichbar ist. Die Leute denken, dass das Schreiben von Code einfach von alleine und vorzugsweise schnell geschieht. Ich habe oft Gespräche mit Kollegen geführt, in denen sie scherzhaft erwähnten, dass alles, was sie von mir hören wollen, "Computer sagt ja / nein?" Ist. Wie lange etwas Neues dauern könnte, wird sehr oft unterschätzt. Das kontinuierliche Schreiben von Tests wird normalerweise als Zeitverschwendung angesehen. Das bringt mich zu meinem nächsten Punkt ...

Gute Software wird in der Wissenschaft nicht geschätzt, zumindest nicht in der gleichen Weise wie in der Industrie.

Das Maß für die Kompetenz in der Wissenschaft sind Veröffentlichungen und die Form der Währung ist Zitate. Sie sind ständig in einer Art Wettbewerb, um etwas Neues und Nützliches zu entwickeln, und nur der erste da draußen wird den Preis erhalten. Klone existieren im akademischen Bereich nicht oder überleben nicht besonders lange. Im Gegensatz dazu können Sie in der Industrie Marktanteile durch bessere Werbung, eine coolere Benutzeroberfläche oder einen niedrigeren Preis gewinnen. Wenn im akademischen Bereich bereits eine Methode veröffentlicht wurde, müssen Sie etwas anderes tun.

Wenn Sie bereits eine Methode veröffentlicht haben, werden zusätzliche Funktionen, Bereinigungen, Optimierungen usw. dieses Proof-of-Principles hinzugefügt Software ist oft nicht gut genug, um eine neue Veröffentlichung zu rechtfertigen, was praktisch bedeutet, dass Sie monatelange Arbeit für nichts verschwendet haben. Traurig aber wahr ...

Erwartungen ändern sich, man muss das Unerwartete erwarten

Könnte ein kleiner Punkt sein, aber ich kann ihn nicht genug betonen, da er mich immer wieder in den Rücken beißt. Sie erhalten einfach nicht die richtigen Spezifikationen für ein neues Projekt. Sie sind oft entweder allzu vage oder viel zu streng (unrealistisch). Manchmal stellt sich heraus, dass etwas, das nie erwähnt wurde, implizit erwartet wird. Um die Verletzung zusätzlich zu beleidigen, ändern sich die Spezifikationen basierend auf einem neuen Datenformat, einer anderen Datenbank, neuen Funktionen oder einfach nur der anderen coolen Sache, an die der Chef gedacht hat, als er auf einer Konferenz war ... Sie schreiben und schreiben Lösungen für die Das gleiche Problem wird zu einer Unordnung.

Normalerweise erhalten Sie nicht die Unterstützung, die Sie benötigen.

Die wenigen Programmier-Doktoranden in meiner Abteilung versuchen wir, uns zu verbessern, indem wir auf dem neuesten Stand bleiben mit den Trends. Best Practices zum Beispiel über SO lernen. Aber meistens sehen Sie Hindernisse, wenn Sie etwas Neues ausprobieren möchten. Entweder denkt die IT-Abteilung, dass Sie zu lästig sind, oder der Chef denkt, dass Sie nachlassen, oder die Leute, die Sie um Hilfe bitten, denken, dass Sie es nicht wissen und dass Sie ihre verschwenden em> Zeit. Zum Beispiel habe ich mehrere Monate lang verhandelt und hin und her geschickt, um von zu Hause aus auf unseren Versionskontrollserver zugreifen zu können. Schließlich funktioniert es nur schneller, bestimmte Best Practices zu überspringen.

Die neuesten coolsten CS-Trends sind für Leute, die keine Experten sind, nicht immer gut dokumentiert.

Ich habe versucht, mir mit mehreren "neuen" Technologien die Hände schmutzig zu machen, die oft welche haben steile Lernkurve. Manchmal ist es die Mühe wirklich nicht wert. Das beste Beispiel, das ich habe, ist Maven. Da ich oft in Java arbeite, dachte ich, ich sollte moderne Tools für das Packen und das Abhängigkeitsmanagement verwenden. Aber meine Schlussfolgerung, nachdem ich so lange damit gekämpft habe, ist @% & $ it! Ich habe wirklich nicht die Energie oder Zeit, um das Durcheinander einer Dokumentation durchzugehen.

Fazit

Nachdem ich mich in den letzten Jahren darüber Sorgen gemacht hatte, kam ich zu folgendem Schluss, der mir inneren Frieden verschaffte:

" Ich bin kein Softwareentwickler. Ich bin weder ausgebildet noch ausgebildet Das Schreiben von Software ist nicht meine Aufgabe. Das Lernen, bestimmte Probleme zu lösen, ist . "

Ich hoffe, diese Antwort gibt es Sie erhalten einige Einblicke, warum von Wissenschaftlern geschriebene Software (außergewöhnlich talentiert oder auf andere Weise) häufig nicht den von Softwareentwicklern festgelegten Standards entspricht.

Nur um die großartigen Antworten von Marc Claesen und cbeleites zu ergänzen. In der Wissenschaft ist es beim Schreiben von Code üblich, dass:

Persönlich (von) reiner akademischer Hintergrund), ich habe die meisten guten Codierungspraktiken in der Zusammenarbeit mit anderen gelernt:

• durch Lernen von anderen - einige Codierungspraktiken erfordern nicht viel von Brainpower, aber viel Erfahrung - die Weisheit, dass eine bestimmte "intelligente Lösung" auf längere Sicht problematisch wird (wie die meisten Kludges (= hässliche Hacks)),
• durch Zusammenarbeit - oft wurde mir klar, dass das, was für mich einigermaßen klar war, ein völlig unverständlicher cthulhu fhtagn (und dennoch mächtig) für andere war (und umgekehrt als Nun - ein netter Code für jemand anderen war ein herausforderndes Rätsel für mich.
• Alles in allem gehen viele gute Praktiken tatsächlich auf den kleinsten gemeinsamen Nenner der Fertigkeiten (und nicht kluge Leute sind schon nah dran); kluger Code von einem wird für andere schwierig sein.

Und ein Dessert - der Fluch der Begabten , ein Kommentar zum letzten Punkt:

Sie sind ein brillanter Implementierer, fähiger als ich und möglicherweise (ich sage dies nach Überlegung und in aller Ernsthaftigkeit) der beste in der Unix-Tradition seit Ken Thompson selbst. Infolgedessen leiden Sie unter dem Fluch des begabten Programmierers - Sie stützen sich so sehr auf Ihre Fähigkeiten, dass Sie nie gelernt haben, bestimmte Arten der Selbstdisziplin und der handwerklichen Gestaltung zu schätzen, die weniger Sterbliche müssen entwickeln, um die Art der Problemkomplexität zu bewältigen, die Sie zum Frühstück essen.

(Quelle: http://lwn.net/2000/0824/a/esr-sharing. php3; oder abgekürzt: http://www.linuxtoday.com/infrastructure/2000082800620OPCYKN)

Und es wurde von Eric S. Raymond bis Linus Torvalds...

Und als Randnotiz (da die Programmierung immer häufiger wird) erkennen Wissenschaftler jetzt, dass bewährte Verfahren und Arbeitsabläufe wichtig sind z.B http://software-carpentry.org/.

Könnten Sie selbst als professioneller Softwareentwickler entwickeln, dass Sie eine gute Software nennen, wenn die Anforderungen wöchentlich auf unvorhersehbare Weise variieren? Dies ist die Welt, in der Forscher überleben.

Wissenschaftliche Forschung bedeutet, unerforschte Gebiete zu betreten. Die Forscher wissen nicht, welche Funktionen sie morgen früh vom Monster benötigen könnten. Dies hängt von den Ergebnissen ab, die sie heute um Mitternacht erzielen. Ein wissenschaftliches Programm sammelt zu viele Iterationen und fügt Funktionen hinzu, die jedoch niemand jemals benötigen würde.

Alle Versuche, Platz für neue Funktionen zu lassen, Modularität hinzuzufügen und die Situation oft noch zu verschlimmern, wenn diese "generischen Ansätze" später gehackt werden müssen, um weitere Änderungen drastischer als erwartet (und unterstützt) vorzunehmen ) durch das "generische Framework".

Daher kann ein Programm, das sich während des Forschungsprozesses direkt entwickelt, häufig nur als Prototyp verwendet werden und muss neu geschrieben werden, bevor es als kommerzielle oder auch als FOSS-Software veröffentlicht wird. Ein professioneller Programmierer könnte, wenn er eingestellt wird, wahrscheinlich etwas besser abschneiden, aber die Instabilität der Anforderungen verhindert höchstwahrscheinlich die "Ankunft" des wirklich großartigen endgültigen Designs.

Warum hat Roald Amundsen keine Autobahn zum Südpol gepflastert?

Warum hat Edmund Hillary auf dem Weg zum Mount Everest keinen Skilift gebaut?

Der Job von Akademikern ist es, Lösungen für Probleme zu finden, die bisher für unmöglich gehalten wurden, anderen beizubringen (und trotz des in ihren Zuschussvorschlägen enthaltenen Kesselschilds ist diese Zielgruppe andere Forscher ), wie das Problem zu lösen ist, und das oben Genannte zu tun so effizient wie möglich.

Akademiker kümmern sich nur insoweit um die Qualität ihres Codes, als er "gut genug" als Proof of Concept ihrer Ideen funktioniert und möglicherweise in zukünftigen Projekten wiederverwendet werden kann. Das Umgestalten von Code, das Schreiben von Dokumentationen, das sorgfältige Überprüfen von Fehlern, das Einrichten automatisierter Builds usw. ist Zeitverschwendung, es sei denn, die Zeit, die für die Verbesserung der Software aufgewendet wird, spart ihnen mindestens genauso viel Zeit beim Generieren von Arbeitsergebnissen. Für die vier Punkte, die ich aufgelistet habe, ist dies fast nie der Fall.

Wenn sich ihre Forschung als praktisch wichtig herausstellt, werden viele Forscher zurückgehen und ausgereifte Implementierungen ihrer Forschung schreiben frühere Algorithmen (normalerweise als Teil einer Beratungsvereinbarung mit professionellen Softwareentwicklern), und sie hatten die Ausbildung und das Talent, dies früher zu tun - es war einfach nicht die Zeit wert.

In vielerlei Hinsicht ist das Schreiben von Software eine Kunst. Viele große Maler wurden nicht so geboren, sie haben die Kunst tatsächlich in jahrelanger Ausbildung und mit vielen schlechten Ergebnissen dazwischen gelernt.

Nehmen Sie ein Blatt Papier und versuchen Sie, jemanden zu zeichnen, den Sie kennen. Selbst wenn Sie ein Bild vor sich haben, wird es höchstwahrscheinlich komisch aussehen. Jetzt würde ein echter Künstler Sie fragen, warum Sie die Schatten nicht gesehen haben, nicht die richtige Perspektive gefunden haben oder die Ohren an die völlig falsche Position gebracht haben, obwohl Sie ein klares Bild vor sich hatten. Es ist jedoch nicht Ihre Arroganz, die das verursacht hat, sondern Ihre mangelnde Erfahrung, das Modell richtig zu betrachten. Technisch hat es etwas damit zu tun, dass Sie die falsche Gehirnhälfte verwenden, und Sie können darauf trainiert werden, dies zu ändern. Nur erst morgen.

Wissenschaftler arbeiten theoretisch. Sie haben eine Theorie, sie wollen sie beweisen, sie schreiben Code, der sich nur auf die eigentliche Theorie konzentriert. Das heißt, Sie sehen eine Nase, aber nicht die Schatten um sie herum. Wenn Sie ihnen monatelang oder vielleicht jahrelang beibringen würden, die richtigen Techniken und "Striche" anzuwenden, um es richtig zu machen, könnten sie sich ändern. Sie sollten sich jedoch fragen, ob sich das lohnt. Manchmal ist es so, aber manchmal sollten sich Wissenschaftler einfach so sehr an wissenschaftliche Dinge halten, wie Maler nicht plötzlich aus heiterem Himmel mit der radioaktiven Chemie beginnen sollten.

Wenn Sie sich entscheiden, sie zu unterrichten, behalten Sie die Idee des Künstlers bei, der anfängt an seinem ersten Tag im Sinn: Es ist nicht ihre Arroganz, es ist ihr Mangel an Wissen darüber, wie man die richtigen Teile des Gehirns benutzt. Es gibt einen Grund, warum "Softwareentwicklung" eine 3-jährige Ausbildung ist, nach der Sie als "Anfänger" gelten.

Großartige Diskussion, und ich habe das schon oft gedacht. Es gibt auch eine andere Art von Software, die oben nicht wirklich erwähnt wurde - Programme, die im akademischen Bereich entwickelt wurden und nicht Teil eines Forschungsprojekts sind. Es gibt viele Softwareentwicklungsprojekte, die sich mehr auf Logistik, Unterricht usw. konzentrieren (Clicker, Videoaufzeichnung, Intranets, Bibliothekssoftware usw.). Manchmal werden diese professionell gehandhabt und werden zu Kooperationsprojekten usw., aber sehr oft sind sie das Ergebnis von jemandem, der einige Assistenten hat, die sich mit Programmierung auskennen und etwas programmieren, das vielleicht funktioniert - aber natürlich keine Dokumentation, Tests oder Version hat Kontrolle, Anforderungsdokumentation usw. - und wenn sie ihren Abschluss machen und weitermachen, viel Glück für alle, die versuchen wollen, sie aufrechtzuerhalten ... Ein Teil davon ist auch die "falsche Wirtschaft" der Wissenschaft, in der bestimmte Arten von Arbeitskräften extrem billig sind / kostenlos (für die Menschen, die davon profitieren).

Ich persönlich bin wahrscheinlich auch für einige beschissene Software verantwortlich, als Doktorand im computergestützten Lernen. Ich bin mir hoffentlich ein bisschen bewusster für Best Practices, Versionskontrolle usw. als viele andere, aber ich hatte noch nie eine Berufsausbildung, und was vielleicht noch wichtiger ist, ich war nie Teil einer Community of Practice, die von besseren Forschern betreut wurde usw. In der Ausbildung ist es in gewisser Weise noch schwieriger, weil es nur sehr wenige technisch versierte Studenten / Professoren gibt. Ich benutze natürlich SO, Mailinglisten usw. sehr häufig, aber ich bin sicher, dass mein Code massiv verbessert werden könnte, wenn ich einen älteren Kollegen auf dem Flur hätte, der meinen Code überprüft und Feedback gibt usw.

In der Tat hat mich einer der obigen Kommentare zum Nachdenken gebracht - es ist durchaus üblich, dass Universitäten statistische Berater haben, die Forschern in gewissem Umfang zur Verfügung stehen. (Wir haben jemanden in unserer Bibliothek, auf den wir ein oder zwei Stunden lang kostenlos zugreifen können, und dann müssen wir eine Gebühr zahlen, aber ich weiß, dass viele Leute davon profitieren und es sehr hilfreich fanden, sich mit ihnen zusammenzusetzen und Durchgehen ihres Forschungsdesigns, ihrer Annahmen, des statistischen Designs usw.). Es wäre ein interessantes Konzept, einen "Softwareentwicklungsberater" zu haben (der sich über den Titel nicht sicher ist), der im Grunde genommen ein professioneller Code-Reviewer wäre ... Aber er könnte auch dazu beitragen, dass Menschen ihre Bedürfnisse durchdenken, nützliche Frameworks herausfinden oder Bibliotheken, Navigationskontrolle, Open Source-Lizenzen usw.

Und natürlich ist es unglaublich wichtig, das Anreizsystem dahingehend zu ändern, dass qualitativ hochwertiger Code freigegeben (oder verbessert!) wird, aber sehr schwierig. Ich denke, Mozillas Übung Academic Code Review ist in dieser Hinsicht ein wirklich interessantes Experiment.

Zurück zum Schreiben von Python-Skripten zum Parsen von MOOC-Clicklogs :)

Weil Programmieren wie Autofahren ist: Jeder braucht es, aber die meisten von uns sind keine Profis. Wie lernt man Programmieren? Kauft / leiht in der Regel ein Buch "Python oder was auch immer für Anfänger". Es geht darum, wie man eine Datei speichert, ein Programm ausführt und eine Funktion aufruft. Danach kann ich das meiste tun, was ich jetzt oder gestern dringend benötige.

Wo werde ich mehr über Entwurfsmuster, gute Softwareentwicklungspraktiken, agile Entwicklung und das Schreiben von schönem Code erfahren? NIRGENDWO! Genau wie nach einem Autokurs glaube ich, dass es mir gut geht, und ich lese nicht 5 Stunden am Tag darüber, wie man schneller auf nasser Straße fährt. Ich gehe nicht in Buchhandlungen und lese jedes einzelne CS-Buch es kann mit mir verwandt sein. Selbst wenn ich ins Netz gehe, ist Software Carpentry vielleicht die einzig relevante Ressource! Im Ernst, wenn jemand etwas Ähnliches weiß, bitte, Post ist irgendwo hier!

Ich werde kein Mondlicht haben, um eine vollständige CS in MIT-Kursunterlagen zu lernen, um mein "Hallo Wort" des Tages zusammen zu hacken. Und ich wäre nicht überrascht, wenn selbst CS-Leute am MIT die Hälfte der guten Programmierpraktiken außerhalb der Schule lernen würden, am Arbeitsplatz und nicht nach 4-5 Jahren in der Schule.

Zusammenfassung: Replikation oder deren Fehlen.

Details:

Meine Beobachtungen (leider kleines n und ein einzelner POV) sind der Hauptgrund Sowohl nicht als auch talentierte Wissenschaftler schreiben, dass schreckliche Software einfach "das Gegenteil von Replikation" ist. Sie sehen keinen Wert in reproduzierbarer Forschung, sie erwarten nicht, dass ihre Arbeit repliziert wird, und sie wünschen sicherlich nicht, dass ihre Arbeit repliziert wird. (Sie möchten nur, dass ihre Arbeit zitiert :-)

Ich bin ein BSCS, der Zeit "in der Industrie" verbracht hat, einschließlich eines bekannten gesichtslosen Akronyms. Alle Programmierer, die ich kannte, verwendeten und schätzten zumindest Open-Source-Software, und viele trugen dazu bei (vor allem bei meinem letzten direkten Code-Gig). OSS wird nur in dem Umfang bewertet, in dem es verwendet und erweitert wird. (AFAICS - fehlt mir etwas? Exotische Sprachen, die studiert, aber nicht verwendet werden?) Natürlich wird ein bestimmtes OSS nur verwendet, wenn es robust, getestet / testbar, gut dokumentiert usw. ist (und nur erweitert, wenn es öffentlich ist).

Jetzt bin ich als Umweltmodellierer (meistens atmosphärisch) wieder zur Schule gegangen. Die Leute, mit denen ich meistens zusammengearbeitet habe, stellen ihren Code nicht einmal in ein öffentliches Repository (selbst die viel jüngeren als ich - dies ist kein AFAICS-Generationsproblem), geschweige denn erstellen Dokumentation, Modularität, Kommentare (ob in Code oder in Commits) und die anderen Vorteile, die man in OSS erwartet. Dies scheint darauf zurückzuführen zu sein (ausschließlich auf Konversation - keine starken empirischen Daten), dass sie davon ausgehen (und normalerweise hoffen), dass ihr Code nicht nur nie von jemand anderem verwendet wird (und wahrscheinlich auch nie wieder vom Codierer verwendet wird) ), aber niemals gesehen werden .

Leider habe ich das nicht verstanden, als ich als Student "eingestellt" habe. (Ich wusste fast nichts über Hochschulabsolventen - ich war gerade bei dem gesichtslosen Akronym "aus dem Fenster gesprungen" und wusste nur, woran ich arbeiten wollte - und war besonders ahnungslos in Bezug auf die kulturellen Unterschiede zwischen Informatik ("Informatik") berühmt falsch benannt) und "harte Wissenschaft".) Ich wählte als meinen Berater den Professor, dessen Arbeitsbereich mich am meisten interessierte. Als ich anfing, seinen Code zu betrachten, war mein Erbrechen Projektil. Ich habe versucht, ihn darüber zu informieren, und seine Haltung war ungefähr (d. H. Kein Zitat) "Papiere sind wichtig, Code nicht." Er hat niemals Code mit Papieren eingereicht oder Code veröffentlicht und fast ausschließlich eine ziemlich obskure, {proprietäre, teure} {Sprache, Entwicklungsumgebung} verwendet (wie, um fair zu sein, viele seiner Kollegen, von denen einige sehr große Namen sind in unserem kleinen Feld). Ich hatte einen naturwissenschaftlichen Hintergrund und wusste, dass die Modelle, an denen wir arbeiten, echte Auswirkungen auf die öffentliche Ordnung haben (z. B. ernsthafte Ausgaben), und fragte, wie man seine Ergebnisse reproduzieren könnte. Er sagte (und dies ist ein Zitat): "Sie müssen uns vertrauen - wir sind Wissenschaftler." Er ist nicht länger mein Berater ...

Während ich (wieder auf kleinem n) vermute, dass die obigen Beobachtungen "die zentrale Tendenz messen", ist nicht alles Dunkelheit und Leere :-) In meinem eigenen Bereich, Es gibt beispielhafte Software wie GEOS-Chem. Leider ist GEOS-Chem aufgrund des GEOS-Chem-Supportteams, das eine in meinem Bereich erstaunlich seltene Infrastruktur bietet, "das, was es ist" (IMHO). Daher vermute ich, dass GEOS-Chem die Softwarequalität über diesen Bereich mit hoher Abdeckung gemessen hat (fehlt mir etwas?), Wahrscheinlich 2-4σ besser als der Mittelwert.

Die kurze Antwort auf diese Frage lautet, dass Wissenschaftler (meistens) keine Softwareprogrammierer sind (obwohl sie von Zeit zu Zeit Software veröffentlichen).

Ich arbeite in einem rechenintensives Feld, was bedeutet, dass viele der verschiedenen Dinge, an denen ich in der Vergangenheit gearbeitet habe, in eine Software gepackt werden können. Aus eigener Erfahrung sind hier einige Hindernisse, die mich davon abhalten, eine vollwertige Software zu schreiben, die auf meiner Arbeit basiert:

1. Ein Großteil meiner Forschung ist unbefristet Untersuchungen, daher ist der Code auch für diesen Zweck geschrieben . Das Schreiben einer Software bedeutet, dass ich ein grundlegendes Verständnis für alles habe, was ich bisher erforscht habe, was nicht der Fall ist (und in absehbarer Zukunft nicht der Fall sein wird).

2. Jedes der Dinge, an denen ich gearbeitet habe, ist einzeln zu klein, um als Software geschrieben zu werden . Um den Umfang der Dinge zu erweitern, ist Forschung erforderlich, keine Software.

3. Ein Großteil der Forschung liegt außerhalb meiner Kontrolle. Es wird immer neue Möglichkeiten und Richtungen für die Forschung geben, was bedeutet, dass einige Forschungen (und der dazu geschriebene Code) abgebrochen werden , dies geht auf die oben genannten Punkte zurück.

4. Meistens schreibe ich MATLAB-Code unter Windows. Selbst wenn ich mein Betriebssystem nicht wechsle (um Linux zu sagen), kann ich MATLAB-Code in eine .NET-Sprache übersetzen oder als C / C ++ - Objekt exportieren. Ich könnte mich irren, aber ich denke, dass Softwareentwicklung in beiden Sprachen schwierig und zeitaufwändig ist .

5. Der Grund, warum die meisten Forschungsingenieure Code mit MATLAB schreiben, ist, dass die Bearbeitungszeit in der Forschung sehr unterschiedlich ist. In den meisten Fällen müssen die Dinge wöchentlich erledigt werden, und dies kann sehr neuartige Experimente beinhalten. Wenn es voll wird, kann die Bearbeitungszeit innerhalb des Tages liegen. Diese Experimente werden optimal mit einer sehr stabilen Plattform wie MATLAB oder Mathematica durchgeführt, während Ihr Code für einige andere Sprachen nicht kompiliert werden kann, wenn Sie versehentlich irgendwo eine Registerkarte einfügen oder einen Doppelpunkt übersehen. Dies treibt wiederum die Dinge an, die ich in den obigen Punkten erwähnt habe, und verschlechtert die richtigen Fähigkeiten in der Softwareentwicklung weiter, obwohl Sie Code schreiben.

6. Ein Kommentator erwähnte, dass die Softwareentwicklung beim maschinellen Lernen großartig abschneidet. Aus meiner Sicht liegt der Grund dafür darin, dass in Bereichen wie Optimierung, maschinelles Lernen, Signalverarbeitung A. Dinge sichtbar sind, B. Dinge seit den 1950er Jahren untersucht wurden, C. viele Menschen versuchen, sich darauf einzulassen In diesem Bereich, D. viele Dinge sind ehrlich gesagt einfach, rechnerisch gesprochen und oft reicht eine ungenaue Lösung (die in ganz besonderen Fällen funktioniert) aus. Leider arbeiten die meisten von uns nicht in so praktischen Bereichen .

7. Ehrlich gesagt, haben wir alle ein Leben jenseits der Forschung . Die Softwareentwicklung kann persönliches Engagement oder Zusammenarbeit erfordern, die länger als die gesamte Dauer eines Forschungsprojekts dauert.

ol>

Ich glaube nicht, dass ich ein talentierter Forscher bin, aber ich habe in Software geforscht und tatsächlich eine Software produziert. Für dieses Stück habe ich auch mit einigen Leuten eines großen Technologieunternehmens zusammengearbeitet. Offensichtlich war unser Ansatz in Bezug auf Software sehr unterschiedlich.

• Als ich die Software schrieb, wählte ich den einfachsten Weg, um zu demonstrieren, dass meine Ideen korrekt sein sollten. Ich habe nicht viel Zeit damit verbracht, die Software zu entwickeln, weil ich keine Zeit hatte! Ich habe mich sehr bemüht, es zum Laufen zu bringen, und ich habe versucht, es lesbar und hackbar zu machen (weil ich weiß, dass irgendwann jemand anderes es übernehmen wird), aber ich habe nicht viel Zeit damit verbracht, es zu entwickeln. Ich war hauptsächlich daran interessiert, es zum Laufen zu bringen, damit ich etwas damit anfangen kann (und zeige, dass meine Ideen richtig sind!)

• Das war eigentlich der gute Teil. Bei meiner Forschung haben wir eine Forschungssoftware-Bibliothek verwendet, die von einer anderen Forschungsgruppe in einem anderen Land erstellt wurde. Sie waren sich eigentlich nicht bewusst, dass Leute ihre Software benutzten! Infolgedessen checkten sie Änderungen ein, die dazu führten, dass die Software nicht erstellt wurde. Außerdem war der Code schwer zu lesen und wir können ihn nicht selbst reparieren (es war C ++, daher sind Fehlermeldungen auch nicht so hilfreich). Wir mussten sie persönlich kontaktieren, um das Problem zu beheben.

• Können Akademiker also gute Software schreiben? Ja, zumindest viele könnten (oder sie könnten keine Programmierkurse unterrichten). Tatsächlich gab es einen Professor von mir, der ein phänomenaler Programmierlehrer war, dessen persönlich geschriebener Code jedoch nicht so angenehm zu lesen ist. Akademiker haben einfach keine Zeit, sich herumzuhacken und ihren Code gut aussehen zu lassen. Wenn sie mehr Zeit gehabt hätten, ihre Software zu verbessern, würden sie es sicher tun.

• OTOH, die Leute im Technologieunternehmen waren tatsächlich daran interessiert, Software zu produzieren, die sie verwenden konnten (und auf diese Weise vielleicht einige Forschungsarbeiten zu produzieren). Sie folgten ihren Kodierungsstandards. Sie haben es tiefgreifend entwickelt. Sie verwendeten Build-Management, Integrationstests und Abdeckungstests. Sie tun es, weil (1) sie Zeit und Geld haben und dafür bezahlt werden und (2) sie es tatsächlich benutzen werden!

Eigenschaften, die einen guten Wissenschaftler ausmachen, sind nicht immer ein guter Softwareprogrammierer (außer, wie das OP hervorhob, wenn die "Wissenschaft" zufällig Informatik ist.

Computercodierung ist Eine hochpräzise Kunst. Viele Menschen, einschließlich guter Wissenschaftler, sind nicht präzise genug, um leicht guten Code zu schreiben. Dies gilt insbesondere für die "intuitiveren" Arten von Wissenschaftlern.

Viele Wissenschaftler finden Computerprogrammierung "langweilig" "Und aus diesem Grund machen Sie es nicht gut. Es ist wahr, dass" normale "Wissenschaft Detailarbeit erfordert, aber nicht bis zu dem Grad der Programmierung, den viele (einschließlich Ihrer wirklich) als" betäubend "empfinden.

Wenn zwischen einem guten Wissenschaftler und einem guten Programmierer keine (oder nur eine sehr schwache) Korrelation besteht, erhalten Sie von einer Population von Wissenschaftlern die gesamte Bandbreite an Programmierfähigkeiten, die gut, mittelmäßig und schrecklich sind.

Es gibt drei Hauptgründe.

Einer ist, dass Wissenschaftler keine professionellen Softwareentwickler sind. Das gilt auch für Informatiker und vor allem für Mathematiker, Physiker, Chemiker, Biologen, Sozialwissenschaftler und so weiter. Nicht, dass sie es nicht könnten, die meisten Leute, die einigermaßen schlau sind, könnten professionelle Softwareentwickler werden, wenn sie wollten, aber die meisten sind es nicht.

Zwei ist, dass Wissenschaftler nicht daran interessiert sind, das Gegenteil von "schrecklicher Software" zu schaffen. Sie interessieren sich normalerweise nur für die Ergebnisse. Dies ist schlecht, wenn ihre Software Fehler enthält, die zu falschen Ergebnissen führen, aber nahe genug an der Wahrheit liegen, um plausibel zu erscheinen. Glücklicherweise führen viele Fehler zu Ergebnissen, die offensichtlich falsch sind. Es ist auch schlecht, wenn die Software so verwirrend ist, dass niemand sicher sagen kann, ob sie korrekt ist oder nicht, aber meines Wissens gibt es nicht viele Beschwerden darüber.

Und drei ist, dass Wissenschaftler oft unter Zeitdruck stehen. Sie schreiben möglicherweise schnell Software, von der sie wissen, dass verbessert werden sollte, und sie wissen möglicherweise sogar, wie sie verbessert werden müssen, aber sie haben einfach nicht die Zeit dafür.

Eine Sache, von der ich wirklich hoffe, dass sie nicht der Grund ist, ist, dass manche Leute denken, dass alles, was sie verstehen, einfach und alles, was sie nicht verstehen, schwer sein muss. Mit diesen Annahmen würde jeder Wissenschaftler, der Software schreibt, die niemand verstehen kann, als Genie angesehen, während jeder, der Software schreibt, die leicht zu verstehen ist, überhaupt nicht sehr beeindruckend wäre. Was ein professioneller Softwareentwickler tut und Software macht, die leicht zu verstehen ist, würde Ihrer Karriere nach Ansicht dieser Leute schaden. Ich hoffe wirklich, dass dies nicht der Fall ist, aber ich wäre nicht überrascht.