Wie kogntivie Verzerrungen uns dazu bringen Code-Problem zu übersehen, wie wir unsere Meinungen gegen Daten verteidigen & was dagegen hilft.
Falls Du in der Softwareentwicklungs-Branche unterwegs bist, dann hast Du diesen Satz bestimmt schon häufiger gehört. Von Kollegen, Lieferanten, Kunden oder Geschäftspartnern. Am häufigsten aber natürlich von Dir selbst. Du hast ihn laut ausgesprochen, bewusst mitgedacht oder implizit angenommen.
Warum? Weil es das ist, was Du wahrhaftig glaubst. Alles andere wäre eine persönliche Katastrophe, nicht wahr? Und obwohl ich selbst zu 100% davon überzeugt bin, dass mir der Großteil der Probleme in meinem Code nicht bekannt ist, ertappe ich mich viel zu häufig bei dem gegensätzlichen Gedanken.
Kürzlich las ich den sehr empfehlenswerten Artikel “Warum wir glauben, was wir glauben wollen”. Reto U. Schneider fasst dort wissenschaftliche Erkenntnisse aus der Psychologie und Neurobiologie zusammen, die unser schwieriges Verhältnis zu unseren eigenen Meinungen darlegen. Kurz gefasst: unsere Gehirne sind stets bestrebt, um jeden Preis an bestehenden Meinungen festzuhalten – ganz unabhängig vom Verhältnis dieser Meinungen zur Realität.
Meinungen werden oft nicht aus Fakten, Analyse und Intelligenz geboren, sondern aus Inkompetenz, Selbstüberschätzung und Opportunismus.
— Reto U. Schneider
Beim Lesen des Artikels konnte ich nicht aufhören, an die Softwareentwicklung zu denken. In erster Linie vermutlich, weil ich schon seit meinem 13. Lebensjahr programmiere und ohnehin viel zu häufig an das Zeug denke. Auf der anderen Seite aber auch deswegen, weil das Schreiben von Code sehr viel mit Meinungen zu tun hat.
Warum? Nun, ein Code-Stück ist letztendlich bloß unsere Meinung darüber, was die beste Lösung für die Umsetzung einer Anforderung ist. Für fast jede Problemstellung gibt es einfach zu viele mögliche Lösungsvarianten, als dass man sich objektiv auf nur eine richtige festlegen könnte. Und so produzieren wir als SW-Entwickler laufend Meinungen, die wir “per Definition” gegen alles und jeden verteidigen (so wollen es eben unsere Gehirne).
Mitnichten! Inkompetenz, Selbstüberschätzung und Opportunismus sind auch in der SW-Entwicklung Gang und Gäbe.
Oder copy-pasten wir nicht etwa halbgares Zeug aus Stackoverflow zusammen, das die meisten Likes hat? Entscheiden nach Bauchgefühl, wo sich Testabdeckung lohnt und wo nicht? Und benutzen auch schon mal die neueste Technologie (nach 2-3 YouTube-Videos), die wir nicht ganz verstehen, nur weil es gerade “in” ist? Oder machen das alles immer nur die Anderen?
Das Tückische an Meinungen ist, dass sie, entgegen verbreiteter Annahmen, beinahe immun gegen Fakten sind. Wir identifizieren uns so sehr mit unseren Meinungen, dass wir einen Meinungswechsel als einen Verrat an unserem jetzigen und früheren Selbst empfinden.
Wir haben nicht Meinungen, wir sind unsere Meinungen
— Reto U. Schneider
Diesen unangenehmen Gefühlszustand (auch Kognitive Dissonanz genannt) versucht das Gehirn, automatisiert zu vermeiden, in dem es sich die Welt so zurecht legt, wie es gerade passt. Diese Automatismen führen zu systematischen Fehlern (sogenannten kognitiven Verzerrungen) bei der Wahrnehmung der Realität, denen wir alle unterliegen. Einer der Bekanntesten ist der Bestätigungsfehler (Confirmation Bias) – die Neigung, Informationen gezielt so auszuwählen, dass sie unsere Meinungen bestätigen (auf Wikipedia sind über 50 weitere kogntive Verzerrungen gelistet).
Hand aufs Herz: Wieviel Zeit muss vergehen, bis Du Dir völlig uneingeschränkt und ohne Scham eingestehen kannst, dass ein von Dir geschriebenes Codestück totaler Mist war? Bei mir sind es 1 – 2 Jahre. Davor werde ich davon überzeugt sein, dass es vernünftige Gründe dafür gab, es so zu machen und nicht anders. Versteht mich nicht falsch, es geht nicht um bewusstes Lügen. Wir können bloß nicht über den Tellerrand dessen Hinausblicken, was wir für wahr halten – es ist die einzig uns zugängliche Realität.
Ähnliches mag auch für andere Berufe gelten. In der SW-Entwicklung kommt man aber sehr häufig zunächst straffrei davon und kann sich viel zu leicht ein falsches Sicherheitsgefühl verschaffen. In dieser Deutlichkeit ist mir das erst gegen Ende meines Studiums klar geworden, als mir beim Löten einer Schaltung ein Transistor in die Luft gegangen ist. Es hat laut geknallt und das Allerschlimmste: ich musste in den Laden einen neuen kaufen.
Beim Entwickeln hingegen können wir so oft auf “compile” & “run” klicken und Dinge zurecht biegen, bis sie irgendwie funktionieren – ist eben SOFT-Ware. Ohne echte Angst im Nacken sinkt die Motivation für mentale Anstrengung und davon macht das Gehirn Gebrauch, wann immer es kann: Nachdenken ist ein Kalorienfresser und Gehirne liebes es, Ressourcen zu schonen.
Angesichts der Menge an Fehlern, die sie machen und der Fehlentscheidungen, die sie treffen. Wer diesbezüglich noch Illusionen verspürt, solle bitte schön einen Blick in seinen Bug-Tracker werfen. Welche Branche sonst noch führt derart sorgfältig Listen über eigene Misserfolge? Und trotz alledem halten wir uns alle für unfehlbare Experten, die über sich selbst und andere bestens Bescheid wüssten.
Subjektives Überzeugtsein ist kein objektiver Maßstab für die Richtigkeit von Urteilen.
— Daniel Kahneman.
Diese einleuchtende Wahrheit ist tatsächlich eine unüberwindbare Hürde für uns: alles was wir tun, tun wir aus Überzeugtsein. Denn eines ist klar: wir schreiben sub-optimalen Code nicht vorsätzlich. Wir sind stets von seiner Richtigkeit überzeugt. Den Großteil der Zeit sind wir verdammt dazu, unseren Intuitionen zu vertrauen. Wir sind unsere Intuitionen. So funktioniert unsere Lebensbewältigung. Andernfalls würden wir vor ständigen Zweifeln verrückt.
Die Anzahl an Memes darüber, was alles in der SW-Entwicklung falsch läuft, ist aberwitzig. Und so könnte man geneigt sein zu glauben, dass die Branche sensibler gegenüber der eigenen Fehleranfälligkeit sein sollte. Aber Pustekuchen – scheinbar sind SW-Entwickler auch nur Menschen. Wir akzeptieren und bestätigen mit Bereitwilligkeit und rationaler Kühnheit die Probleme unserer Branche, unseres Unternehmens, unserer Kollegen und unserer engsten Freunde.
Sobald es aber um uns selbst geht, fangen wir an Bullshit zu reden.
Der Glaubenssatz im Titel ist das Urproblem an Fehlentwicklungen in der SW-Entwicklung. Ein weiterer, der uns in der einen oder anderen Form in Kunden-Projekten und -Gesprächen begegnet, ist der folgende:
Analyse-Tools bestätigen nur das, was ich ohnehin weiß, der Rest sind False-Positives
Nun, es ist absolut nachvollziehbar, so etwas über seinen eigenen Code zu glauben. Es ist die Folge einer weiteren kognitiven Verzerrung, die Daniel Kahneman als die WYSIATI (What You See is All There Is) – Regel bezeichnet:
Wir können einfach nicht anders, als mit den beschränkten Informationen, die wir besitzen, so zu verfahren, als wären sie alles, was man über das Thema wissen kann. Aus uns verfügbaren Informationen konstruieren wir die bestmögliche Geschichte, und wenn es eine gute Geschichte ist, glauben wir sie. Paradoxerweise ist es leichter, eine kohärente Geschichte zu entwerfen, wenn man wenig weiß […] Unsere beruhigenden Überzeugung, dass die Welt einen Sinn hat ruht auf einem sicheren Fundament: unserer beinahe unbegrenzten Fähigkeit, die eigene Unwissenheit zu ignorieren.
— Daniel Kahneman.
Wir kennen zum Großteil nur die problematischen Codestellen, die wir entweder selbst bewusst verursacht haben (als Technische Schulden) oder diejenigen, wo vermehrt Fehler auftreten, die in unseren Zuständigkeitsbereich fallen. Das ist genau die beschränkte Information, die uns zur Verfügung steht.
Falls Analyse-Tools genau dort Red Flags anzeigen, freuen wir uns über Bestätigung (Confirmation Bias), dem Rest begegnen wir mit Skepsis und Ablehnung (Motivated Reasoning – unsere Tendenz Widersprechendem besonders kritisch zu begegnet und Gründe dagegen zu finden).
Erstens, weil Fehler nur einer von vielen Indikatoren von Unzulänglichkeiten sind. Beispielsweise sind auch solche Codestellen hoch-problematisch, die zwar bisher keine Fehler verursachen, jedoch viel Entwicklungszeit beanspruchen, weil sie schwer verständlich sind (was unserer Aufmerksamkeit aber häufiger entgeht, weil sie nicht die Prägnanz eines aufgetretenen Fehlers haben).
Zweitens, weil wir nichts darüber wissen, worüber wir nichts wissen. Mit anderen Worten: Die Abwesenheit unseres Wissens über Probleme ist kein Indikator für die Abwesenheit der Probleme selbst. Entsprechende Erkenntnisse helfen uns aber kaum dabei, unsere Glaubenssätze zu ändern.
Vor einiger Zeit kamen wir auf der TNW-Konferenz mit einem technischen Manager ins Gespräch. Er hörte sich unsere Ausführungen über daten-basierte Software-Analysen an, nickte und bezeichnete die Ansätze als interessant. Zumindest für die Zukunft. Denn zur Zeit hätte er noch einen ganz guten Überblick über seine Software. Dazu muss man wissen: der gute Mann hatte Projekte in über 60 Repositories zu verantworten.
Die Erkennung der eigenen Fehlbarkeit ist an sich schon ein sehr schwieriges Unterfangen. Könnte es aber sein, dass die Arbeitsweise in Softwareprojekten diese inhärente Problematik zusätzlich noch verschärft?
Dass Manager einerseits das First-Time-Right-Prinzip in einem für Software unberechtigten Ausmaße voraussetzen und Entwickler somit gezwungen sind, aus Angst vor Benachteiligung, ihre Fehlentscheidungen zu verstecken? Und dass Entwickler andererseits (ebenfalls unberechtigterweise) den Managern stillschweigend jegliches realistische Verständnis für die Unbeständigkeit von architektonischen Entscheidungen absprechen und somit das Vortäuschen von Unfehlbarkeit als die einzig legitime Überlebensstrategie ansehen?
Unsere Projekterfahrungen sowie Gespräche mit Managern und Entwicklern legen nahe, dass leider beides wahr ist: Das Verhältnis ist tatsächlich in beide Richtungen sub-optimal und häufiger als notwendig von gegenseitigen Schuldzuschreibungen geprägt.
Dieses Thema ist aber zu umfangreich, um in nur einem Abschnitt abgehandelt zu werden und hat einen separaten Post verdient.
Wenn man der Forschung Glauben schenkt, leider nicht allzuviel. Wir haben kaum Möglichkeiten unseren Biases zu entfliehen. Meistens verwenden wir unseren Verstand dazu, die Widersprüche zu unseren Überzeugungen wegzuerklären, anstatt aus ihnen zu lernen.
Nichtsdestotrotz glaube ich nicht, dass wir ganz chancenlos sind. Es gibt einige Stellschrauben, an denen wir drehen können.
Das ist unsere einzige Chance, sie ab und zu auszutricksen, damit sie das machen, was wir wollen, und nicht umgekehrt. Dazu zwei Buchempfehlungen, die nichts mit Software zu tun haben:
Dieser Mythos wird leider immer noch viel zu häufig aufgewärmt. Wir sind nicht mehr oder weniger Künstler als Fliesenleger und Versicherungsvertreter. Jede Tätigkeit kann mit einem Grad an Exzellenz ausgeführt werden, der an Kunst grenzt. SW-Entwicklung auch – sie ist diesbezüglich aber keine Ausnahme unter den anderen Berufen.
Nein, wir sind keine Künstler, wir haben uns “Software-Engineering” auf die Fahne geschrieben. Und als Ingenieure müssen wir lernen, weniger Willkür und mehr Disziplin an den Tag zu legen.
Das bedeutet auch: weniger Vertrauen ins Bauchgefühl und mehr Offenheit für daten-basierte Erkenntnisse, die unsere Meinungen auch widerlegen könnten.
Das ist der Beitrag, den wir versuchen mit Cape of Good Code zu leisten. Und tatsächlich zeigt Daniel Kahneman in seinem Buch, dass einfachste Algorithmen häufig bessere Urteile liefern als Experten.
Kleine Verbesserungen machen einen großen Unterschied. Ein wenig mehr Recht zu haben, ist besser, als komplett im Dunklen zu tappen.
Robert Sapolsky schreibt dazu im letzten Kapitel seines 800-Seiters:
On any big, important issue it seems like 51 percent of the scientific studies conclude one thing, and 49 percent conclude the opposite. And so on. Eventually it can seem hopeless that you can actually fix something, can make things better. But we have no choice but to try.
Und dem gibt es eigentlich nichts hinzuzufügen.
Praktischer Letifaden darüber, wie man durch die richtige Auswahl von Issue-Typen die Softwarequalität verbessert und ein effektives Monitoring...
Fallstricke agiler Remote-Entwicklung und Gegenmaßnahmen für eine effektive Zusammenarbeit in räumlich verteilten Teams.
Strukturelle Abhängigkeitsanalysen sind nur begrenzt aussagekräftig bei der Identifikation von Architektur-Hotspots. Es gibt präzisere Alternativen.