- Auch im Zeitalter des agentischen Codings wird die Nachfrage nach Software Engineers voraussichtlich eher steigen; der Kern liegt nicht im Schreiben von Code, sondern in der Fähigkeit, Services zu betreiben
- Code zu schreiben war schon immer der einfache Teil; wirklich schwierig ist es, Systeme über lange Zeit stabil zu betreiben
- Wie bei No-Code und Tabellenkalkulationen können auch Nichtfachleute Werkzeuge bauen, doch die Last von Wartung und Betrieb erfordert am Ende professionelle Engineering-Kompetenz
- Nutzer kaufen keine Software, sondern Services; gute Software sollte unsichtbar funktionieren
- Operative Exzellenz (operational excellence) – Uptime, Fehlerrate, Wiederherstellungsgeschwindigkeit, Sicherheitsupdates – ist der Schlüssel zur künftigen Wettbewerbsfähigkeit
- Als Rolle, die all diese Anforderungen erfüllt, rückt SRE ins Zentrum des Software Engineerings
SRE dürfte zum meistgesuchten Berufsbild werden
- Wenn Code billiger wird, gewinnt am Ende operative Exzellenz
- Greenfield-Demos kann jeder bauen, aber um einen Service stabil zu betreiben, braucht es Engineering-Kompetenz
- "Jeder will Greenfield-Demos schreiben, aber niemand will Services betreiben"
- Software Engineering ist nicht bloß Programmierung, sondern das Management von Systemen, die sich im Laufe der Zeit verändern
Die Lehre aus dem Zeitalter von No-Code und Tabellenkalkulationen
- Der Buchhalter Joe verkürzte eine wiederkehrende Aufgabe, die wöchentlich 10 Stunden kostete, mit No-Code-Tools und Spreadsheet-Makros auf 1 Stunde
- Anfangs war der Erfolg deutlich, doch mit der Zeit nahm die Komplexität schnell zu
- Veränderungen im Geschäftsumfeld, geänderte Buchhaltungsregeln sowie Probleme mit Zeitzonen und Sommerzeit summierten sich
- Jede Woche traten neue Edge Cases zutage, wodurch laufende Nacharbeit und Korrekturen nötig wurden
- Am Ende geriet Joe in einen Zustand, in dem er an das von ihm gebaute System gebunden war
- Selbst im Urlaub musste er an das System denken, und es war schwer, den Betrieb an jemand anderen zu übergeben
- Schon das Ausführen des Codes und das Prüfen der Ergebnisse wurde selbst zu einem Auslöser für Angst und Anspannung
Die Computer-Krankheit (The Computer Disease)
- Ein von Feynman geprägter Begriff: Das Problem mit Computern ist, dass man ständig daran herumdoktern will
- Automatisierung an sich macht Spaß, doch es gibt die Falle, auch Bereiche zu automatisieren, in denen es gar nicht nötig ist, und so die Komplexität zu erhöhen
- Die eigentliche Last liegt im Betrieb von Services
- Sie stabil funktionsfähig halten
- In großem Maßstab ohne Probleme skalieren
- Sie über Jahre hinweg kontinuierlich managen
- Bei der Bereitstellung von Services sind Stabilität, Zuverlässigkeit und Beständigkeit entscheidend
Warum operative Exzellenz die Zukunft ist
- Menschen kaufen keine Software, sondern beauftragen einen Service, der ihr Problem löst
- Niemand interessiert sich für die interne Funktionsweise von iCloud; erwartet wird, dass Fotos immer automatisch zwischen Geräten synchronisiert werden
- Wie Word, Notion oder gDocs gebaut wurden, ist nicht wichtig; entscheidend ist die Erfahrung, Gedanken zu schreiben und zu teilen
- Wichtiger als die Struktur des Zahlungsnetzwerks ist das Ergebnis, dass ein Matcha Latte für 7 Dollar problemlos bezahlt wird
- Gute Software ist unsichtbar (sie funktioniert natürlich und ohne sich aufzudrängen)
Die wirklich schwierigen Engineering-Aufgaben
- Die ersten 90 % eines funktionierenden Demos zu bauen ist leicht; die restlichen 190 % sind der wirklich wichtige Teil
- Fragen, die aus Betriebssicht beantwortet werden müssen:
- Wie hoch ist die Uptime?
- Wie hoch ist die Fehlerrate?
- Wie schnell ist die Wiederherstellungszeit bei Ausfällen?
- Werden Probleme erkannt, bevor Nutzer sie bemerken?
- Lassen sich Upstream-Abhängigkeiten beherrschen?
- Werden Vendor-Probleme erkannt, bevor Nutzer sich beschweren?
- Wie lange dauert es, von Nutzern vorgeschlagene Ideen umzusetzen?
- Wird verhindert, dass Engineers gegenseitig ihre Systeme kaputtmachen?
- Gibt es ein System, in dem Engineers weiter vorankommen können, ohne dass die App zu einem chaotischen Gebilde wird?
- Kann man Software in einer Größenordnung handhaben, die nicht mehr in den Kopf eines einzelnen Menschen passt?
- Wenn in einer Zeitzone mit 12 Stunden Zeitunterschied ein großes Problem auftritt, während der Engineer schläft: Wird es behoben, bevor die Nutzer aufgeben?
- Ist eine Wiederherstellung nach eigenen Ausfällen und nach Upstream-Ausfällen möglich, oder gehen wichtige Daten verloren?
- Werden Sicherheitsupdates konsequent eingespielt?
- Kommt es nicht zu einem Abfluss von Nutzerdaten?
- Ist das System vertrauenswürdig?
- Kann man sich darauf verlassen?
- Gibt es Belege, die dieses Vertrauen stützen?
- Kann man eine rechtsverbindliche Garantie unterschreiben, dass die Software bei Bedarf funktioniert?
- Das sind die wirklich schwierigen Engineering-Aufgaben; Code zu schreiben ist der einfache Teil
Noch keine Kommentare.