DE

Das Wissen kam vom Machen

, Korhan Gülseven

This post is only available in German.

Programmieren hat immer zwei Hälften. Die taktische entscheidet, wie der Code aussieht: Syntax, Struktur, Sichtbarkeit. Die strategische entscheidet über Dinge, die man an keiner einzelnen Stelle im Code sehen kann. Was passiert, wenn ein Teil ausfällt. Wo sich unter Last der erste Flaschenhals zeigt.

Immer mehr von der taktischen Arbeit geben wir an Agenten ab. Aus ihr entstand bisher auch die strategische Sicht. Entscheidungen wurden ausprobiert, korrigiert und manchmal verworfen.

Ob zwei Module wirklich unabhängig sind, merkst du nicht bei der Änderung, für die du sie getrennt hast. Du merkst es zwei Jahre später, wenn jemand etwas daneben bauen will.

Diesen Zeitpunkt sieht ein Agent nicht. Sind die Tests grün und die Aufgabe erfüllt, gibt es keinen Anlass weiterzufragen. Er macht dabei nichts falsch: Kopplung erzeugt kein Signal. Ebenso wenig eine Abstraktion, die zwei Dinge zusammenbindet, nur weil sie heute ähnlich aussehen. Ohne Signal gibt es keine Korrektur.

1??

Vieles von dem, was wir über unser System wissen, ist negatives Wissen. Wir wissen, was man hier nicht macht. Warum die naheliegende Lösung schon zweimal schiefgegangen ist. Warum dieses Modul nicht anders geschnitten wurde. Warum eine bestimmte Abhängigkeit an dieser Stelle unerwünscht ist. Tribal Knowledge. Solange dieselben Leute den Code verändern, reicht ein Satz: "Mach das nicht so, das hatten wir schon."

Diesen Satz hört ein Agent nicht.

Für eine Maschine kann ein Ticket klar wirken, obwohl drei Leute im Team es unterschiedlich verstehen würden. Was fehlt, fällt auf. Was mehrdeutig ist, nicht. Unschärfe wird nicht entdeckt, sie wird ausgeführt.

Also alles aufschreiben. Jede verworfene Alternative, jede Abhängigkeit, die aus einem Grund existiert, den niemand mehr kennt. Was bisher im Kopf eines Teams steckte, müsste so dastehen, dass eine Maschine es versteht wie eine Kollegin, die seit drei Jahren im Projekt sitzt.

Wer das versucht, merkt schnell, wo das Problem liegt. Nicht nur darin, dass es viel Arbeit wäre. Manches halten wir für so selbstverständlich, dass wir es gar nicht aufschreiben. Erst wenn jemand anders vorgeht, merken wir, was wir hätten erklären müssen. Und manches lässt sich überhaupt nicht so formulieren, dass es jemand anderes gleich versteht. Implizites Wissen, hat Michael Polanyi das genannt: "We can know more than we can tell."

Bleibt die andere Richtung. Statt alles zu beschreiben, prüfbar machen, was sich überprüfen lässt. Fitness Functions tun genau das, für den Teil, der sich in eine Regel fassen lässt. Eine Regel im Dokument ist eine Empfehlung. Ein Test, der bei jedem Build läuft, macht daraus eine Eigenschaft des Systems: Dieses Paket importiert jenes nicht, diese Antwortzeit bleibt unter diesem Wert. Was sich erst im laufenden System zeigt, lässt sich mit Load Testing oder Chaos Engineering prüfen, wenn jemand die Zeit dafür durchsetzt. Und ob die Trennung zweier Module die richtige war, prüft trotzdem kein Test.

Diese Regeln muss aber jemand zuerst schreiben. Und wer eine Regel schreibt, muss wissen, welches Problem sie verhindern soll. Am Ende fehlt nicht das Verfahren. Es fehlt jemand, der weiss, worauf es ankommt.

Die strategische Hälfte war teilweise ein Nebenprodukt der taktischen: Code schreiben, Dinge kaputt machen, Systeme wachsen sehen, Entscheidungen bereuen und es beim nächsten Mal anders machen. Jetzt geben wir das Bauen ab und damit den Prozess, in dem man das lernt.

Wenn ich weniger selbst baue, muss mehr Zeit in die Prüfung. Prüfen heisst dann nicht mehr bloss Fehler suchen, sondern Entscheidungen hinterfragen, ihre Folgen sehen, daraus lernen. Ich muss sie zu meinen machen.

Im Moment stammt das Wissen noch von denen, die es beim Bauen gelernt haben.


Find me by email, on LinkedIn or via Zooey.