Mir hat dieser Artikel über das Denken zweiter Ordnung sehr gut gefallen.
Er erklärt am Beispiel von 'Chestertons-Fence', warum es wichtig ist, vor Änderungen an Systemen das Denken zweiter Ordnung einzusetzen. Er nutzt dazu die Methapher eines Zauns über eine Straße. Diesen sollte man nicht einfach wegräumen, nur weil er nervt. Warum? Weil die Menschen die ihn gebaut haben hatten damit Aufwand, den Sie nicht einfach nur so zum Spaß investiert haben. Deren Gründe muss man verstehen um zu sehen ob der Zaun tatsächich weg kann, oder nach wie vor nötig ist.
Angenommen hinter dem Zaun befindet sich ein Straßenabschnitt, der mit Minen verseucht ist. Leider ist dies in der Ukraine ja ein häufiges Problem. Der Zaun sollte erst entfernt werden, wenn die Minen geräumt sind, um Todesfälle und Verletzungen zu vermeiden. Die Toten und Verletzten sind hier der Effekt zweiter Ordnung.
Denken zweiter Ordnung heißt also nicht nur zu hinterfragen, warum etwas so ist, wie es ist, sondern auch zu verstehen, warum die Menschen, die es geschaffen haben (in unserem Fall meistens Code), es auf diese Weise gebaut haben. Bevor ich Änderungen vornehme, sollte ich mir Zeit nehmen, um die Gründe für die ursprüngliche Gestaltung zu verstehen, da unbedachte Änderungen unerwünschte Effekte haben werden.
So zu denken finde ich nicht leicht. Oft misslingt es mir. Aber es ist für mich ein Ziel.
Was heißt das für uns Entwickler?
Besonders bei der Frage: Wieso sind unsere Systeme so wie sie sind? Ist das für mich super relevant. Aber auch immer wenn ich Programmiere. Wenn ich einen Zaun aufstelle, also z.B. etwas komplizierter mache als es sein könnte, dann schreibe ich einen Kommentar wieso ich mich gegen die einfachere Lösung entschieden habe, damit die nach mir kommenden verstehen ob meine - für Sie - überkomplizierte Lösung noch nötig ist. Wenn ich eine weiter reichende Entscheidung fälle, dann Dokumentiere ich diese gerne mit eineme Architektural Decision Record (ADR) der enthällt aus welchen Gründen wir uns so entschieden haben. Wenn ich eine Story schreibe, dann muss da nicht nur das Feature drauf, sondern eben auch der Grund dafür, damit ich oder andere später nachvollzieen können, wieso dieses Feature existiert, oder eben wieso es nicht mehr nötig ist. Idealerweise würde ich auch gerne vom Code über die Commits zur Story zurück kommen - aber das gelingt mir bisher regelmäßig nicht.
Fazit
Viele der Praktiken, die wir in der Softwareentwicklung als Standards ansehen, dienen eigentlich dazu, das Denken zweiter Ordnung zu erleichtern – ein wichtiger Zusammenhang, der oft unerwähnt bleibt, mir aber zunehmend klarer wird.
Ganz besonders wichtig ist mir aber der Respekt, im Zweifel sollte ich erst einmal annehmen das der andere sich etwas dabei gedacht hat. Bevor ich das nicht verstehe sollte ich nicht die Axt ansetzen.