Chestertons Fence oder was ist Denken zweiter Ordnung?

written by Martin H├Ącker on

Mir hat dieser Artikel ├╝ber das Denken zweiter Ordnung sehr gut gefallen.

Einsam stehendes Auto vor einem Zaun ├╝ber eine Stra├če

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.