Ein bekanntes Entwickler-Sprichwort sagt: Code wird öfter gelesen als geschrieben. Facundo Olano denkt es weiter und kommt zu einer Prioritätenlehre, die weit über das Schreiben hinausreicht.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügenSein Kerngedanke zur Softwareentwicklung: Code wird öfter betrieben als gelesen. Mit „betreiben“ meint Olano den gesamten Alltag in Produktion, vom Ausrollen über das Beobachten bis zum Abschalten.
Das Wichtigste in Kürze
- Olano ordnet die Beteiligten in eine Rangfolge: Geschäft, Nutzer, Betrieb, Entwicklung.
- Die langfristigen Betriebskosten eines Systems übersteigen den Aufwand beim Bauen meist bei Weitem.
- Viele typische Probleme entstehen, wenn diese Rangfolge verletzt wird.
Was bedeutet „betreiben“ statt nur „ausführen“?
Betrieb vor Eleganz. Ein Programm auszuführen ist das eine, es zuverlässig in Produktion zu halten das andere. Ausrollen, überwachen, prüfen, reparieren, abschalten: Genau dort entstehen die Kosten, die über Jahre anfallen. Olano fasst das in seinem lesenswerten Essay zusammen.
Daraus folgt eine schlichte Konsequenz. Weniger bewegliche Teile bedeuten weniger Fehlerquellen. Das alte KISS-Prinzip bekommt im Betrieb eine neue Bedeutung, weil jede zusätzliche Komponente nachts um drei jemanden aus dem Bett klingeln kann. Wie weit Einfachheit trägt, zeigt unser Bericht, wie eine HTML-First-Website ihre Nutzerzahl verdoppelte.
Woran erkennt man eine verdrehte Rangfolge?
Symptome statt Schuldige. Steht der Autor über dem späteren Betreuer, entsteht cleverer Code, den niemand mehr pflegen mag. Steht die Technik über dem Nutzer, entstehen überkonstruierte Programme, die vertraute Funktionen kaputtmachen. Jede dieser Fehlstellungen lässt sich auf eine vertauschte Priorität zurückführen.
Besonders bissig benennt Olano die „imaginäre Software“, die gebaut wird, aber nie in Produktion geht. Solche Projekte testen ihre Annahmen nie an der Realität und kosten trotzdem volle Aufmerksamkeit.
Diese Rangfolge klingt theoretisch, beschreibt aber den Alltag jedes Teams. Den Betrieb erst nach dem Deployment mitzudenken, rächt sich später doppelt.
— Michael Dobler, Herausgeber Dr. Web
Was nehmen Teams daraus mit?
Perspektive gewinnen. Am Ende stellt Olano selbst das Geschäft über dem Nutzer infrage. Software, die ihre Nutzer manipuliert oder zum Produkt macht, erfülle ihren eigentlichen Zweck nicht. Eine ethische Untergrenze bleibt: dem Nutzer nicht schaden.
Prüfen Sie bei Ihrem nächsten Architekturentscheid, wer am Ende mit dem System leben muss. Eine langweilige, gut beherrschbare Lösung schlägt fast immer die elegante mit vielen beweglichen Teilen.
Mehr Newshunger?
