- 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
8 Kommentare
Haha, 90 190, haha
Hahahahahahahaha
Was soll das denn?
Es wäre noch besser gewesen, wenn es zusätzlich eine Erklärung dazu gegeben hätte, was SRE ist.
Die Reaktionen in den Kommentaren lol, es wirkt, als hätte man aus dem Original nur das Nötige herausgeschnitten~ Hat sich gut gelesen.
Ergebnis der KI-Analyse: Piiiep-Piiiep-Piiiep … mit 95% Wahrscheinlichkeit ein KI-Blog.