IT für Erwachsene

“Ship fast, fail fast” oder manchmal auch “fail cheap” ist ein Credo aus dem agilen Umfeld.¹ Es adressiert ein echtes Problem mit starren Prozessen, Hierarchien oder Technologie-Stacks. Die heutige Industrie verspricht seit Jahren mit agiler Arbeitsweise ein höheres Tempo, was sich richtig anfühlt. Doch wenn ich gefragt werde, ob ich agil arbeiten würde, antworte ich lieber ausweichend.

Viele verwechseln Tempo mit Reife und vergessen dabei, dass eine falsch eingeschlagene Richtung sich nicht mit Geschwindigkeit korrigieren lässt. Geschwindigkeit als Kompensationsmechanismus für fehlende Klarheit.

Möglicherweise oute ich mich gerade als “Internetausdrucker”,² weil ich gute Beiträge nicht “bookmarke”, sondern mit wkhtmltopdf als PDF im Dateisystem ablege.³ Und so verwahre ich seit vielen Jahren einen noch deutlich älteren Beitrag des Business Journalisten Charles Fishman mit dem Titel “They Write the Right Stuff” aus dem Jahr 1996. Früher frei im Netz aufrufbar,⁴ heute hinter einer Paywall.⁵

Seine Beschreibung, was exzellente Software auszeichnet und wie diese das Space-Shuttle zusammenhielt, wirkt wie ein Anachronismus.⁶ Kein Rapid-Application-Development (RAD),⁷ kein Minimum-Viable-Product (MVP)⁸ und erst recht kein agiles “Trial-and-Error” als Management-Prinzip.⁹

Langsam in Entstehung, schnell und stabil im Betrieb

Exzellente Softwareentwicklung ist langsam. Es wird nicht solange ausprobiert, bis es klappt, sondern die Anforderungen werden erst spezifiziert noch bevor auch nur eine Zeile Code geschrieben wird. Das ist keine Meinung, es ist gängige Systemtheorie.¹⁰

About one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do – and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change.

Agile Iteration setzt implizit richtige Problemdefinition voraus.¹¹ Nur wird das meiner Erfahrung häufig und sogar bewusst ignoriert. In einer Umgebung, in der jedes Scheitern teuer, endgültig oder irreversibel ist, führen “Moving Targets”, fehlende Null-Pointer-Checks oder ausgelassene try…catch Fehlerbehandlungen schnell zu einem Totalausfall. Hohe Vermögenswerte oder sogar Menschenleben stehen dann auf dem Spiel ohne zweite Chance, ohne Respawn wie in einem Computerspiel.

Bitte nicht falsch verstehen. Änderungen sind weiterhin möglich und wichtig, nur eben “teurer” gewichtet. Sie sind zu dokumentieren, zu kontextualisieren sowie einem standardisierten Weg zu folgen und am Ende zu testen. Wo agile Arbeitsweisen Vertrauen in den Augenblick geben und individuelle, häufig einsame Entscheidungen bevorzugen, vertraut langsame Softwareentwicklung auf organisatorische Prozesse und Standard Operating Procedures (SOP) zur Fehlerminimierung.¹² Es wird nur dem vertraut, was auch überprüf- und reproduzierbar ist. Verschriftlichung und Versionskontrolle sind nicht nur Hilfsmittel zur Kollaboration.¹³ Es sind unabdingbare Kontrollinstrumente.

Testing als organisierter Wettbewerb

Doch zum Erfolg trägt noch ein anderer organisatorischer Baustein bei: Das Testen. Entwickler und Tester sind zwei Seiten der Medaille. Noch lange vor der Entwicklung des Konzeptes “Gamification”,¹⁴ verstanden es die NASA-Verantwortlichen beide Seiten in einem “friendly adversarial” arbeiten zu lassen:

The central group breaks down into two key teams: the coders - the people who sit and write code – and the verifiers – the people who try to find flaws in the code. (…) They’re in competition for who’s going to find the errors. Sometimes they fight like cats and dogs. (…) The result is a friendly adversarial relationship.

Das stellt heute viele mit einem irrationalen Harmoniebedürfnis ein mentales Problem dar: Softwareentwickler, Projektleiter und Manager gleichermaßen.¹⁵ Das steht auch diametral dem Agile Manifesto entgegen.¹⁶ Die heutige KI‑Rhetorik ist geprägt von der “Corporate Fiction” wie Fortune es unlängst benennt,¹⁷ beide Rollen ließen sich problemlos automatisieren.

Das Mindset ist wichtig

Langsame Entwickler (und Tester) passen schlecht in gängige Erfolgsgeschichten. Sie lassen sich für Fachfremde auch schlecht in Metriken wie Lines-of-Code (LOC)¹⁸ oder (Mean-)Time-to-Resolve oder -Repair (MTTR oder TTR)¹⁹ packen.

Importantly, the group avoids blaming people for errors. The process assumes blame - and it’s the process that is analyzed to discover why and how an error got through. (…) The way the process works, it not only finds errors in the software. The process finds errors in the process.

Die Ausführungen von Charles Fishman dokumentieren eine Organisation mit einem enorm hohen Reifegrad, die “Software for Grown-Ups” produzieren. Nachhaltig, reproduzierbar und sicher.

That’s the culture: the on-board shuttle group produces grown-up software, and the way they do it is by being grown-ups. It may not be sexy, it may not be a coding ego-trip – but it is the future of software. When you’re ready to take the next step – when you have to write perfect software instead of software that’s just good enough – then it’s time to grow up.

Es ist eine Mär, dass Software oder IT-Systeme ständige Pflege, monatliche Hotfixes und Helden im Incident-Fall brauchen. Im Normalfall funktioniert etwas so, wie zuvor spezifiziert. Zuverlässig, fehlertolerant, mit minimaler Downtime, so wie ich unlängst in “Wie sich IT Erfolg messen lässt” darlege.²⁰

Keine Raketenwissenschaft

Jetzt mag der berechtigte Einwand kommen, das alles sei wortwörtlich “Raketenwissenschaft”, Overengineering, schöne Theorie ohne Praxisbezug. Für Normalsterbliche in Unternehmen jenseits aller Budgets. Spezifikationen in der freien Wirtschaft würden sich ständig ändern und die NASA hätte politische Rückendeckung für Langsamkeit.

Nein, nicht wirklich. Das ist kein theoretisches Problem. Es passiert real in ganz normalen Unternehmen. Grundlegende Abläufe bleiben oft über Jahrzehnte gleich. Und was für Unternehmen missionskritisch ist und was nicht, ist immer subjektiv. Der Launch einer funktionierenden ERP-Software ist für ein mittelständisches Unternehmen genauso wichtig, wie der Space Shuttle Start für die NASA. Organisatorische Rückendeckung in Unternehmen bilden die gängigen Normierungen und Audits, sofern sie auch gelebt und nicht nur als Feigenblatt verstanden werden.

Fishman widerlegt diese Einwände eindrucksvoll auf seine Art und Weise. Er unterscheidet zwischen Werkzeugen und Methoden. Und die Anwendung der Methoden, die “Basics”, ist weder kompliziert noch teuer. Es ist vielmehr ein Mindset, eine Ingenieurskunst, die ausgerechnet der Softwareentwicklung abhanden gekommen ist:

The most important things the shuttle group does – carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code – are not expensive. The process isn’t even rocket science. Its standard practice in almost every engineering discipline except software engineering.

Vielleicht bin ich in den letzten Jahren zu oft auf Geschäftsführer und Entscheider getroffen, die Reifeprozesse stets als Bürokratie und Hemmnisse abstempelten. Umso wichtiger ist es, daran zu erinnern, dass gute Software und erfolgreiche IT-Projeke kein Zufall sind. Sie sind das Ergebnis von Disziplin, Klarheit und erwachsener Ingenieurskunst.

In diesem Kontext gefällt mir das Slow-Code-Manifesto sehr.²¹

In diesem Sinne,
Euer Tomas Jakobs