Niemand weiß wirklich, wie Softwareprodukte tatsächlich funktionieren [Übersetzung]

1. Intransparenz großer Tech-Systeme

• Selbst große Tech-Unternehmen betreiben ihre eigenen Systeme im „fog of war“.
• Selbst auf grundlegende Fragen wie „Können Nutzer vom Typ Y Funktion X verwenden?“, „Was genau passiert bei Aktion Z?“ oder „Wie viele Tarifmodelle gibt es derzeit?“ können innerhalb der Organisation nur wenige antworten.
• Im schlimmsten Fall muss eine Person eigens für die Untersuchung abgestellt werden, obwohl die Antwort eigentlich schon aus der öffentlichen Dokumentation hervorgehen müsste – was sie aber nicht tut.

2. Die Quelle der Komplexität: Wicked Features

• Große Software wird durch Self-Hosting, kostenlose Testphasen, Organisations-/Policy-Steuerung, mehrsprachige Lokalisierung, Compliance-Funktionen usw. extrem komplex. Diese Funktionen beeinflussen jede neue Funktion.
• Beispiel: Wird Policy-Steuerung hinzugefügt, muss sie jedes Mal auch auf neue Funktionen angewendet werden; bei Lokalisierung müssen Übersetzungen ebenfalls nachgezogen werden.
• Ob „ein Enterprise-Kunde mit Self-Hosting in einer EU-Region Zugang zu einer bestimmten Funktion hat“, lässt sich oft nur durch direkte Untersuchung des Codes oder durch Experimente klären. Solche Funktionen wegzulassen hieße, enorme Umsätze aufzugeben – ein zentraler Unterschied zwischen großen und kleinen Unternehmen.

3. Die Grenzen der Dokumentation

• Theoretisch ließen sich bei neuen Funktionen alle Interaktionen dokumentieren, aber das System verändert sich schneller als die Dokumentation.
• In einer dynamischen statt statischen Umgebung müssten Dokumentationsverantwortliche den Änderungen immer voraus sein – das ist praktisch unmöglich.
• Das größere Problem: Viele Verhaltensweisen entstehen nicht aus expliziter Absicht, sondern aus dem Zusammenspiel von Default-Einstellungen – ihre Dokumentation gleicht daher der Erkundung des realen Systems.

4. Der Kern der Antwort: Codebasis und Engineer:innen

• Präzise Antworten bekommt man nur durch direkten Blick in die Codebasis – darin liegt auch die Machtbasis von Engineer:innen.
• Eine Kernfunktion von Engineering-Teams ist die Fähigkeit, Fragen zur Software zu beantworten.
• Dabei wird implizites Wissen (tacit knowledge) genutzt, das zu bestimmten Codebereichen im Kopf einzelner Menschen existiert.
• Bei Teamumbauten geht dieses Wissen verloren, sodass „explorative Chirurgie“ nötig wird (Code anpassen, Checks erzwingen usw.).
• Code zu schreiben ist leicht, aber zuverlässige Antworten zu geben ist wegen der nötigen Sicherheit schwierig (Risiko, falschzuliegen, und die Notwendigkeit zur Verdichtung in einer Zusammenfassung).

5. Fazit: Eine wertvolle Fähigkeit

• Menschen außerhalb technischer Rollen glauben oft, Software werde von Engineer:innen vollständig verstanden, aber große Systeme versteht in Wahrheit niemand vollständig.
• Selbst grundlegende Fragen erfordern immer wieder neue Untersuchungen, und mit Veränderungen entstehen Nuancen und Ausnahmen. Die Fähigkeit, präzise Antworten zu geben, ist extrem wertvoll.