Letzte Woche habe ich ordentlich viel Zeit damit verbracht, toten Code aus unserer Codebasis zu entfernen. Ich möchte den Code löschen. Was mich betrifft, so bringen so wenige Dinge das gleiche Vergnügen wie das Ordnen von Dingen im Code. Ja, ich liebe es so sehr, dass ich von den Ingenieuren verwirrt bin, die unnötigen Code in der Anwendung belassen. Aber am Wochenende hörte ich jemanden über Milgrams Experiment "Unterwerfung unter die Autorität" sprechen ( sie schrieben auch im Hub darüber) - und ich konnte nicht anders, als eine Parallele zwischen der Person zu ziehen, die einen anderen Menschen schockierte, und dem Ingenieur, der hinterlässt bekannte Fehler und schlechten Code.
Wenn Sie mit dem Stanley Milgram-Experiment nicht vertraut sind, besteht es darin, dass der Experimentator (eine Person mit Autorität) dem Lehrer (dem Gegenstand des Studiums) befiehlt, den Schüler in einer Reihe zunehmender Stromentladungen zu schlagen, die sich in einem anderen Raum befinden. Wikipedia Abbildung:
E-Experimentator, T-Lehrer, L-Lernender
Die Essenz des Experiments bestand darin, die Reaktionen der Menschen auf Ordnungen zu untersuchen, die ihren moralischen Prinzipien widersprechen. Vor dem Experiment wurde angenommen, dass die meisten Probanden das Experiment beenden würden, sobald sie merkten, dass sie den Schüler verletzten. Während des Experiments stellte sich jedoch heraus, dass eine bemerkenswerte Anzahl von Probanden eine maximale Entladung von 450 Volt erreichte.
In der ersten Reihe von Milgrams Experimenten verwendeten 65 Prozent der Teilnehmer (26 von 40 Personen) den maximal möglichen Wert von 450 Volt, obwohl es für sie nicht angenehm war, dies zu tun; Zu einem bestimmten Zeitpunkt stoppte jeder Teilnehmer und bezweifelte das Experiment. Einige Teilnehmer wollten anhalten und das Geld zurückgeben, das sie für die Teilnahme bezahlt hatten. Während des Experiments waren die Teilnehmer unterschiedlich aufgeregt und gestresst. Sie schwitzten, zitterten, stotterten, bissen sich auf die Lippen, stöhnten, gruben ihre Nägel in die Haut, einige lachten nervös.
Wenn wir von solchen Ergebnissen erfahren, möchten wir glauben, dass wir das niemals tun würden. Wir möchten glauben, dass "nur Befehle befolgen" ein menschlicher Fehler ist, den wir nicht haben. Experimente wie Milgrams Experiment zeigen jedoch, dass ein solcher Glaube bestenfalls optimistisch und im schlimmsten Fall völlig falsch ist.
Und jetzt, da wir wissen, wie Menschen auf Autorität reagieren, wenn es um körperlichen Schmerz geht, wollen wir sehen, wie Programmierer auf Autorität reagieren, wenn es um abstraktere Dinge wie Frustration und Unannehmlichkeiten geht. Nehmen wir das Milham-Experimentdiagramm und entwerfen es neu, um das Entwicklungsteam widerzuspiegeln:
Wenn wir uns das Entwicklungsteam wie in der Abbildung gezeigt ansehen, ist es nicht so überraschend, warum wir Ingenieure schlechten Code hinterlassen und bekannte Fehler hinterlassen. Wahrscheinlich hat die an der Macht befindliche Person irgendwann klargestellt, dass wir keine Zeit haben, die Probleme zu beheben, oder dass diese Probleme im Vergleich zu anderen Dingen in der Roadmap keine Priorität haben. Oder dass das Entfernen von totem Code dem Benutzer keinen Wert bringt. Infolgedessen lassen wir den Code unverändert und fahren mit der nächsten Aufgabe fort, obwohl dies im Widerspruch zu unserem moralischen Kompass und den Konzepten dessen steht, was gut und was schlecht ist.
In Milgrams Experiment zögerten die Probanden oft und protestierten dagegen, eine weitere Entlassung an eine Person in einem anderen Raum zu senden. In solchen Fällen forderte der Experimentator die Fortsetzung eines der vordefinierten Sätze:
- "Bitte weiter" (Bitte weiter / Bitte weiter);
- "Experiment erfordert, dass Sie fortfahren";
- "Es ist absolut wichtig, dass Sie fortfahren" (Es ist absolut wichtig, dass Sie fortfahren);
- "Sie haben keine andere Wahl, Sie müssen weitermachen".
Mit nur Worten konnte der Experimentator sicherstellen, dass 65 Prozent der Probanden gegen ihren Willen andere Menschen mit sehr schmerzhaften Stromentladungen schlugen. Ich frage mich, welche Wörter wir im Zusammenhang mit der Softwareentwicklung verwenden.
- Wir entscheiden nicht, sondern das Produktteam
- Wir müssen die Frist einhalten
- Das Marketing-Team wird nächste Woche eine Pressemitteilung veröffentlichen.
- Wir schließen zu wenige Tickets
- Wir werden diesen Code trotzdem wegwerfen
- Dies ist eine vorübergehende Lösung.
- Sie müssen die Leistung Ihres Teams verbessern
- Dies betrifft eine kleine Anzahl von Benutzern.
- Dies hat für uns derzeit keine Priorität.
- Wir werden es später beheben
- Das will das Management
- Warum so lange?
- Müssen es schneller machen.
Ich schreibe nicht darüber, um eine Lösung vorzuschlagen. Ich habe ihn nicht. Ich schreibe, um - vor allem in mir - Sympathie und Verständnis zu pflegen. Wenn ich einen Code sehe, der ein Gefühl der Verwirrung oder des Verhaltens hinterlässt, das ich nicht verstehe, muss ich daran denken, dass Handlungen nicht immer Absichten widerspiegeln. Ich muss daran denken, dass Ingenieure schlechten Code hinterlassen, nicht weil es ihnen egal ist - sie hinterlassen schlechten Code, weil sie nicht die Freiheit hatten, ihn in Ordnung zu bringen. Und sie hinterlassen Fehler nicht, weil sie sich nicht um Benutzer kümmern, sondern weil sie nicht befugt waren, von der Produkt-Roadmap abzuweichen.