Convention over configuration: Die Wechselwirkung zwischen Softwaredesign-Paradigma und Entwicklerkopf

Autor: Carsten Negrini

Die zunehmende Komplexität in der Softwareentwicklung hat dazu geführt, dass man über die Einführung von Konventionen versucht, den Umfang notwendiger Konfigurationen zu vereinfachen.
Beispielsweise versucht man, die Verbindung von Eingabeelementen über die Objektklassen bis hin zu den Datenbankmodellen durch eine gleichartige Benennung von Klassen und Tabellen sicherzustellen.
Durch eine solche Konvention wird sowohl die Konfiguration dieser Verbindung unnötig als auch das Implementieren der Klassenmethoden, die das Laden von Datenbankinhalten in die Eingabeelemente und das Speichern von Änderungen aus den Eingabeelementen in die Datenbank realisieren.
Damit kann das Leben der Entwickelnden deutlich vereinfacht werden.

Wie so oft im Leben gibt es auch hier Aspekte, die auf den ersten Blick gerne übersehen werden:
Erstens müssen alle Beteiligten jeweils alle verwendeten Konventionen kennen. Wenn jemand die Konventionen nicht kennt, wird es sehr aufwändig, fremden Code zu verstehen und zu warten.
Dieser Aspekt wird zukünftig noch an Bedeutung gewinnen, da verteilte Teams, auch international, inklusive vieler remote Mitarbeitenden im Heimbüro immer mehr zum Normalfall werden. Damit ist der Informationsaustausch zwischen erfahrenen und unerfahreneren Teammitgliedern mit einer größeren Hemmschwelle verbunden als bei zwei Menschen, die sich im selben Raum befinden.

Zweitens darf man nicht ignorieren, dass Convention over Configuration zwar die sichtbare Komplexität des Codes senkt, aber eben nur die sichtbare. Der Code, der beispielsweise Daten zwischen Eingabeelementen und Klassenvariablen transportiert, ist dennoch vorhanden. Man kann zwar argumentieren, dass dieser Code ja millionenfach verwendet wird und daher besonders gut getestet und sehr robust ist, dennoch hat man eine implizite Abhängigkeit.

Auf ganz hoher Flughöhe kann man den Vergleich mit einem Konzept der Psychologie anstellen:
Hier gibt es eine Unterscheidung zwischen „explizitem Wissen“ (bewusstes Wissen, verbalisierbar und damit außerhalb des eigenen Gedächtnisses speicherbar) und „implizitem Wissen“ (unbewusstes Wissen, nicht vollständig verbalisierbar, damit nicht außerhalb des eigenen Gedächtnisses ablegbar).
Für eine Arbeitsorganisation bedeutet das, dass Mitarbeitende mit hohem implizitem Wissen weniger wertschöpfend sind als Mitarbeitende, die in ihrer Arbeitsleistung vielleicht insgesamt weniger Leistung erbringen können, dafür aber einen höheren Anteil an explizitem Wissen mitbringen, welches an andere Mitarbeitende weitergegeben werden kann.
Dies liegt daran, dass man explizites Wissen durch Schulungen und die Möglichkeit der Speicherung dieses Wissens skalieren kann.

Vergleicht man dieses Konzept mit dem Softwaredesign, so ist klar, dass ein explizites Design einem impliziten Design in den Aspekten der Lesbarkeit und damit Skalierbarkeit überlegen ist. Auch ist die Lernkurve bis zum Verständnis des Codes flacher als bei sehr umfangreich verwendeten Konventionen.

Dieses Fazit ist kein Gegenargument gegen Convention over Configuration, es soll aber verdeutlichen, dass Unternehmenserfolg noch andere Aspekte als Softwaredesign beinhaltet. Und auch Softwaredesign ist ein wichtiger Bestandteil des Unternehmenserfolges, genauso, wie die Menschen, die letztlich die Software bauen.

Links:
clean_code.md: https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29
Architektur-Spicker: https://www.embarc.de/img/spicker/Architektur-Spicker8_Nachhaltiges-Software-Design.pdf
Implizites Wissen: https://www.edu.tum.de/fileadmin/tuedz01/www/Downloads/03Fakultaet/Professoren_Fotos/Schelten-Publikationen/2002bukschelteniw.pdf