Wieso wir «Move fast and break things» falsch verstehen — und wie wir Software besser machen können

«Move fast and break things» war bis vor zehn Jahren das Motto von Facebook. Ohne Kontext wird es aber missverstanden und missbraucht. Vor ein paar Monaten las ich einen tollen Artikel von Glyph, der diese Verständnislücken eindrucksvoll füllt. Nun gibt es diesen Text auch auf Deutsch: Für alle, die besser verstehen wollen, wie Software heute entsteht und was das für Digitalisierung bedeutet.

Unter dem Titel «Safer, Not Later» («Sicherer, nicht später») veröffentlichte Glyph, ein erfahrener Softwareentwickler, vor einigen Monaten einen Artikel, in dem er die Missverständnisse rund um «Move Fast and Break Things» auszuräumen versucht. Den Artikel publizieren wir hier mit freundlicher Genehmigung des Autors als Übersetzung, da er wichtige Aspekte der Softwareentwicklung beleuchtet. Der Artikel gibt die Meinung des Autors wider und nicht die Ansicht der DNIP-Redaktion. Ziel der Übersetzung war ein guter Lesefluss und hohe Verständlichkeit. Feinheiten der Sprache haben dabei zwangsweise gelitten; dafür gibt es aber immer das Original.
PS: Keiner der ursprünglich maschinell übersetzten Sätze hat die Hand-Nacharbeit 1:1 überlebt.

«Safer, Not Later», oder: Wie „Move Fast and Break Things“ die Welt ruiniert hat, indem es in unzähligen anderen Kontext angewendet wurde, als in demjenigen, für den es ursprünglich gedacht war.

Facebook — und damit auch der Grossteil des Silicon Valley — wird zu Recht für seinen alten Wahlspruch «Move Fast and Break Things» kritisiert.

Als Motto für das eigene Leben ist das natürlich grosser Quatsch und war damit Ursache etlicher der furchtbaren Folgen von Facebooks Geschäftspraktiken.

Ich möchte die Handlungen von Facebook nicht entschuldigen. Ich möchte auch nicht die Weltanschauung rechtfertigen, die zu solchen Resultaten führt. Jedoch möchte ich versuchen, Laien ein Verständnis zu ermöglichen, was Software-Ingenieure tatsächlich damit meinten; vor allem diejenigen, die dabei waren, als dieses Motto geprägt wurde. Ich möchte, dass mehr Menschen aus der breiten Bevölkerung verstehen, warum es für Ingenieure ungefähr dasselbe bedeutet wie Facebooks neueres, ziemlich doof klingendes «Move fast with stable infrastructure» (wörtlich: «Bewege dich schnell, mit stabiler Infrastruktur»).

Langsam und vorsichtig…

In den schlechten alten Zeiten, also etwa um 2005, prallten in der Softwarebranche gerade zwei Welten aufeinander.

Die alte Welt war die Welt der integrierten Hardware-/Softwareunternehmen wie IBM und Apple und der Softwareunternehmen wie Microsoft und WordPerfect, deren Produkte in Reih und Glied in Verkaufsregalen standen. Die neue Welt bestand aus Software-as-a-Service-Unternehmen wie Google und eben auch Facebook.

In der alten Welt wurde Software auf Disketten in einem physischen Karton ausgeliefert, schön eingeschweisst und im jährlichen Veröffentlichungszyklus. Wenn Softwareunternehmen wirklich aggressiv waren, konnten Sie Updates vierteljährlich ausliefern. Schneller war nicht möglich, denn Ihre physische Produktions- und Versandinfrastruktur konnte nicht mit den neuen Versionen Schritt halten. Es gab also keinen Grund, die internen Entwicklungszyklen schneller ablaufen zu lassen.

In der Praxis der alten Welt bedeutete dies, dass die Entwicklung einer neuen Version mit wilden Experimenten von möglichen neuen Funktionen für diese nächste Version begann. Natürlich führte das zu instabiler, fehlerbehafteter Software. Erst später im Entwicklungszyklus gingen die Programmierer langsam dazu über, weniger zu programmieren und mehr zu testen, um schliesslich in den letzten Monaten vor der Veröffentlichung nur noch zu testen und Fehler zu beheben.

Daraus entstand das Konzept der „Alpha“- (Entwicklungstests) und „Beta“-Versionen (Benutzertests). In dieser ersten Phase der instabilen Entwicklung war es sehr wahrscheinlich, dass die Software nicht richtig funktionierte oder sogar abstürzte. Jeder verstand das. Wie hätte es denn auch anders sein können? Bei einem Alphatest hatten die Software-Ingenieure noch nicht einmal mit der Fehlerbehebung begonnen!

Der Kulturwechsel

In der neuen Welt war die Idee eines 6-monatigen „Betatests“ unlogisch. Wenn es sich bei Ihrer Software um eine Website handelte, lieferten Sie sie jedes Mal an die Benutzer aus, wenn diese im Browser auf „Aktualisieren“ drückten. Die Software lief rund um die Uhr auf Hardware, die Sie kontrollierten. Sie konnten jederzeit Tag und Nacht neue Funktionen hinzufügen. Und da dies nun möglich war, mussten Sie diese Funktionen hinzufügen. Sonst würden sich Ihre Benutzer langweilen und zur Konkurrenz wechseln, die regelmässiger neue Features hinzufügten.

Dazu musste der Umgang mit Qualität und Zuverlässigkeit aber völlig umgekrempelt werden. Wenn eine neue Funktion innerhalb von 24 Stunden bereitstehen musste, war es keine Option mehr, im alten Stil vorzugehen:

1. Zuerst eine fehlerhafte Version zu schreiben, die dann aber ständig abstürzte;
2. danach zu verfolgen, wie eine sorgfältig ausgewählte Gruppe von Benutzern damit arbeitete;
3. die resultierenden Absturzberichte zu sammeln;
4. alle entdeckten Fehler zu beheben;
5. den Funktionsumfang einzufrieren und ein paar Monate lang nichts anderes zu tun als später noch auftauchende Fehler nur zu beheben. Und das alles, ohne in dieser Zeit neue Funktionen einzuführen, welche die Stabilität wieder gefährden könnten.

Sie mussten in dieser neuen Welt in der Lage sein, am Montag eine stabile Version Ihrer Software auszuliefern und dann am Dienstag eine weitere, ebenfalls wieder stabile Version.

Um diese neue Art der Softwareentwicklung zu unterstützen, wurden neue Technologien entwickelt. Ich bin versucht, Ihnen alle zu nennen. Unit-Tests, Continuous-Integration-Server, Fehlertelemetrie, Systemüberwachungs-Dashboards, Feature-Flags, …: Dies ist ein grosser Teil meines persönlichen Erfahrungsschatzes. Während diesem Systemwechsel kämpfte ich an vorderster Front auf Seiten der „neuen Welt“ und versuchte Unternehmen zu immer kürzeren Entwicklungszyklen zu bewegen und sich von der alten Weltanschauung des Wartens auf den grossen „Release Day“ abzuwenden.

Doch lieb gewonnene Gewohnheiten lassen sich nur schwer ablegen. Die meisten Ingenieure waren in einer Welt ausgebildet worden, in der sie nach dem Schreiben ihres ersten groben Entwurfs monatelange Qualitätssicherungsprozesse durchliefen. Solche Ingenieure sind verständlicherweise nervös, wenn sie ihren möglicherweise fehlerhaften Code jeden Tag an zahlende Kunden ausliefern müssen. Sie würden also versuchen, die Dinge zu verlangsamen.

Vorsicht ist die Mutter der Porzellankiste

Wenn man alles beim Alten belässt und nur den Einbau neuer Funktionen beschleunigt, dann geschieht es natürlich irgendwann, dass man einen groben Fehler ausliefert und sich daran die Finger verbrennt. Als Folge wurden Prozesse eingeführt, um alles langsamer und vorsichtiger anzugehen, wie z.B.:

1. Eine besondere Version unseres Codes wird nur zum Testen beiseite gelegt. Diese wird dann einige Wochen lang getestet, bevor wir die Benutzer darauf loslassen.
2. Jede neue Version muss zuerst von einem Abteilungsleiter abgesegnet werden. Als Folge ist ein jeder Entwickler einen ganzen Tag lang nur damit beschäftigt, seine Änderung zu beschreiben und zu begründen.
3. Und natürlich soll auch die Qualitätssicherung ihre Zustimmung geben. Dafür wird ein umfassendes Abnahmeverfahren eingeführt und jeder einzelne Prüfer muss einen detaillierten Testbericht unterschreiben.

Dann gibt es noch meine Lieblingsvariante davon, bei der die Unternehmensleitung beschliesst, dass jegliche Veränderung gefährlich ist und wir Veränderungen deshalb alle lieber ganz sein lassen sollten. Dies geschieht in der Regel in Stufen:

1. Führen wir doch „feature freezes“ ein, also Zeiten, in denen nichts Neues aktiviert oder ausgerollt werden darf. Um das Wochenende nicht mit allfälligen Ausfällen und Fehlersuchen zu verderben, dürfen neu freitags keine Änderungen mehr veröffentlicht werden.
2. Eigentlich sollten wir diesen „freeze“ auf den ganzen Dezember ausdehnen, um das Weihnachtsgeschäft nicht zu gefährden.
3. Warum nicht gleich bis Ende November verlängern? Wir wollen uns schliesslich nicht mit Thanksgiving und dem Black Friday-Wochenende anlegen.
4. Einige unserer Kunden leben in Indien und für die ist Diwali ganz wichtig. Warum die Sperrfrist nicht Ende Oktober beginnen lassen?
5. Wenn wir schon dabei sind: Auch zu Halloween gibt es eine ganze Menge saisonaler Verkäufe. Wie wäre es, wenn wir ab dem 10. Oktober einfach nichts mehr an der Software ändern?
6. Und überhaupt: Manchmal nutzen die Leute unseren Online-Shop auch gerne zum Valentinstag. Es ist also viel sicherer, wenn wir die Software das ganz Jahr durch nie mehr anfassen.

Dasselbe Anti-Pattern (vielleicht am kürzesten als „schlechte Angewohnheit“ zu übersetzen) kann sich bei einer endlos wuchernden Liste von (Test-)“Umgebungen“ wiederholen, deren Hauptaufgabe darin besteht, sicherzustellen, dass kein Code jemals bei den tatsächlichen Benutzern ankommt.

… macht trotzdem Dinge kaputt

Es dürfte Sie kaum überraschen, dass diese Art der Softwareentwicklung ihre eigenen Probleme mit sich bringt.

Schon in den schlechten alten Tagen der 90er-Jahre, als man Disketten in Schachteln verschickte, trug die „alte Methode“ den Keim ihrer eigenen Zerstörung in sich. Wie Joel Spolsky packend formulierte, entdeckte Microsoft damals schmerzhaft, dass die Illusion, nach der man zuerst eine Menge Fehler einführe, die man später einfach beheben könne, mit massiven Nachteilen verbunden war:

«Die allererste Version von Microsoft Word für Windows galt als ein „Todesmarsch“-Projekt. Es zog sich ewig hin. Immer wieder geriet es ins Stocken. Das gesamte Team leistete endlose Überstunden, das Projekt verzögerte sich wieder und immer wieder; der Stress war unglaublich. […]

Man erzählt sich, dass ein Programmierer, der den Code zur Berechnung der Höhe einer Textzeile schreiben musste, einfach «return 12;» schrieb und dann wartete, bis der Fehlerbericht eintraf […].

Der Projektplan war eigentlich nur eine Checkliste von Features, die darauf warteten, in Fehler verwandelt zu werden. Rückblickend nannten wir das dann „Methode der endlosen Fehler“.»

Dies führte zum vielleicht unumstösslichsten Gesetz der Softwareentwicklung:

«Im Allgemeinen gilt: Je länger Sie mit dem Beheben eines Fehlers warten, desto teurer (sowohl in Zeit als auch Geld) wird es, ihn zu beheben.»

Die logische Konsequenz davon: Je länger man mit der Entdeckung eines Fehlers wartet, desto teurer wird es, ihn zu beheben.

Einige Fehler können durch Code Review gefunden werden. Sie sollten also Code Reviews durchführen. Einige Fehler können durch automatisierte Tests gefunden werden. Sie sollten also automatisierte Tests einführen. Einige Fehler werden durch Monitoring mittels Dashboards gefunden, also sollten Sie Monitoring und Dashboards haben.

Warum also nicht schnell handeln?

Hier kommt nun das alte Facebook-Motto ins Spiel. Alle oben genannten Grundsätze sind korrekt, es fehlen aber zwei weitere Punkte:

1. Egal wie viel Code-Review, automatisierte Tests und Überwachung Sie betreiben, einige Fehler können erst gefunden werden, wenn Benutzer mit Ihrer Software interagieren.
2. Fehler finden Sie keine, wenn Sie nur langsam vorgehen und die Auslieferung der Software an die Benutzer einfach immer wieder hinaussschieben.

Wenn Sie den Prozess der Freigabe der Software für Benutzer so sicher gemacht haben, dass der potenzielle Schaden einer bestimmten Änderung zuverlässig begrenzt wird, dann ist es immer am besten, Ihre Änderungen so schnell wie möglich für Benutzer freizugeben.

Selbstverständlich hat jeder Entwickler, jede Entwicklerin von Natur aus Angst davor, etwas kaputt zu machen. Wenn Sie keine Änderungen vornehmen, können Sie nicht dafür verantwortlich gemacht werden, wenn etwas schief geht. Vor allem, wenn Sie in der alten Welt aufgewachsen sind, sind Sie in ständiger Versuchung, die Entwicklung zu verlangsamen, die Auslieferung der Software zu vermeiden und Änderungen zurückzuhalten, einfach nur für den Fall der Fälle.

Sie werden sich langsam bewegen wollen, um zu vermeiden, dass Sie etwas kaputt machen. Es scheint besser, nichts zu tun, nutzlos zu sein, als Schaden anzurichten.

Trotz aller Fehler, die Facebook als Unternehmen macht, verfügt es über eine hervorragende Infrastruktur, die verhindert, dass das Aktivieren einer neuen Funktion den Rest zusammenbrechen lässt. In diesem Sinne hatte Facebook bereits die Arbeit geleistet, um den möglichen „Schaden“ durch Änderungen eines einzelnen Ingenieurs zu verhindern. Es war damit die Aufgabe des Infrastrukturteams, das System so fehlertolerant wie möglich zu gestalten; damit die Softwareentwickler ihre eigentliche Arbeit nicht aus Angst verlangsamen mussten.

Das Problem ist, dass auch eine Verlangsamung ihre eigenen Konsequenzen hat. Um mich selbst hier zu zitieren:

«Wenn du nichts Neues veröffentlichen kannst, kannst du auch keine alten Fehler beheben.»

(Oder im Original: «If you can’t ship a feature, you can’t fix a bug.»)

Wenn Sie um um der Verlangsamung willen langsamer werden, schaffen Sie damit nur noch mehr Probleme.

Das erste Problem, das dadurch entsteht: Sie werfen viel zu viele Änderungen in einen Topf, die dann alle in einem Schwung aktiv werden und die Anzahl möglicher neuer Probleme vervielfachen.

Schauen wir einem typischen Entwicklungsteam über die Schultern: Jeder Ingenieur in diesem Team fügt mit einer bestimmten Rate neue Funktionen hinzu. Sie wollen, dass sie diese Arbeit machen. Alle diese neuen Funktionen werden in den Programmcode integriert, sie sollen ja bei der nächsten Veröffentlichung aktiv werden.

Wenn irgend eine dieser Änderungen ein Problem verursacht, wollen Sie die Ursache rasch finden. Im Rahmen der resultierenden Fehlersuche vergleicht man die Funktionsweise der Software vor und nach diesen frischen Änderungen. Damit diese Suche effizient abläuft, sollten sich diese zwei Versionen der Software möglichst wenig unterscheiden. Ideal wäre eine einzige, klar umrissene und überschaubare Änderung. Alles andere, insbesondere eine gigantische Lawine von gleichzeitigen Änderungen, führt dazu, dass Sie sich innerhalb von hunderten von parallelen Änderungen zu Tode suchen.

Wenn Sie um der Verlangsamung willen langsamer werden, schaffen Sie auch einen Prozess, der nicht auf Fehler des bestehenden Codes reagieren kann.

Bisher entstand der Eindruck, dass die Software vor dieser Änderungen fehlerfrei war und jede Änderung sowohl die Chance auf eine Verbesserung als auch das Risiko eines Rückschritts mit sich bringe. Das stimmt so nicht immer. Änderungen finden nicht nur in Ihrer Software statt. Auch die Welt um Ihre Software herum kann sich verändern und Ihre Software muss in der Lage sein, darauf zu reagieren.

Zurück zu unserem Weihnachtsgeschäft mit „feature freeze“ — also Aktualisierungs-Stopp —, der alle Änderungen in der Weihnachtszeit verbietet, um Ausfälle zu vermeiden. Was passiert, wenn Ihre kleine, aber wachsende E-Commerce-Website einen katastrophalen Fehler aufweist? Einer, der schon immer da war, aber nur auftritt, wenn Sie mehr als 10’000 gleichzeitige Benutzer haben? Der Fehler wird also durch eine Änderung der Welt ausgelöst, durch ein neues, noch nie dagewesenes Mass an Datenverkehr. Das Auftauchen des Fehlers ist auf Ihren Erfolg zurückzuführen, nicht auf Ihren Code. Sie sollten besser in der Lage sein, den neuen Code für die Fehlerbehebung schnell auszurollen. Denn die einzige andere Möglichkeit, den Fehler zum Verschwinden zu bringen, wäre dann, die Website komplett abzuschalten.

Und wenn Sie diesen Fehler zum ersten Mal am Black Friday feststellen, dann ist das Letzte, was sie wollen, zuerst einen neuen Prozess für Rollout am Freitag zu entwickeln. Der einzige Weg, um sicherzustellen, dass diese Fehlerbehebung einfach ist, besteht darin, sicherzustellen, dass jede Fehlerbehebung einfach ist; wenn Ihr gesamtes Team in der Lage ist, solche Probleme rasch zu lösen; egal, in welcher Situation.

Das Motto «Move Fast and Break Things» wurde deshalb im Silicon Valley begierig aufgesogen, weil wir alle diese toxische, lähmende Angst kennen.

Nachdem wir also die Sicherheitsmechanismen haben, die nötig sind, um Änderungen so sicher wie möglich umzusetzen, müssen wir sie nur noch konsequent durchsetzen und akzeptieren, dass Dinge auch mal kaputt gehen können. Aber das ist in Ordnung, darauf sind wir ja jetzt vorbereitet.

Es fehlen noch einige wichtige Worte

Das Motto hat eine implizite Vorbedingung, die nicht vergessen gehen sollte: „Wenn wir darauf hin gearbeitet haben, dass wir auch mit kaputten Dingen klar kommen, dann können wir — ganz im Sinne von «Move Fast and Break Things» —schnell handeln und Dinge auch mal kaputt machen“.

Wenn Sie sich in einem Konflikt darüber befinden, ob Sie „schnell“ oder „langsam“ voranschreiten sollen, soll das Motto Ihnen nicht sagen, dass die Antwort ein unqualifiziertes „Schnell, Hopp-Hopp!“ ist. Es ist vielmehr eine Ermahnung, innezuhalten und die Motivation für die Verlangsamung zu hinterfragen.

Wenn eine Person zu einer Softwareänderung „Mooooment, langsamer!“ sagt, kann sie damit drei Dinge meinen:

1. Die Änderung ist auf eine Weise kaputt, die Sie bereits verstehen. In diesem Fall sollten Sie sie nicht umsetzen, denn sie ist ja noch gar nicht bereit. Wenn Sie bereits wissen, dass sie fehlerhaft ist, dann ist die Änderung einfach noch nicht umgesetzt. Beenden Sie erst Ihre Arbeit und lassen Sie die Benutzer erst darauf los, wenn sie dann fertig ist.
2. Sie ist auf eine Art und Weise riskant, gegen die Sie sich keine adäquaten Schutzmassnahmen haben. Ihrer Ansicht nach funktioniert die Änderung zwar; aber falls nicht, birgt sie ein Risiko, gegen das Sie keine Schutzmassnahmen haben. In diesem Fall sollten Sie die Arbeit an dieser Änderung unterbrechen und zuerst die notwendigen Schutzmechanismen aufbauen.
3. Es macht Sie auf eine Weise nervös, die Sie aber nicht genauer bestimmen können. Wenn Sie keinen bekannten Fehler beschreiben können (siehe Punkt 1) und auch keine verbesserten Schutz benötigen (siehe Schritt 2), dann ist es an der Zeit loszulassen, zu akzeptieren, dass Sie etwas kaputt machen könnten, und schnell zu handeln.

Der implizite Kontext für „schnell handeln und Dinge kaputt machen“ gilt nur in diesem dritten Fall. Also, wenn Sie die Infrastruktur bereits auf stabile Füsse gestellt haben und alle relevanten Fehler der Neuerung behoben haben, dann (und nur dann) hindert Sie nichts daran, auch schnell zu handeln: Denn dann bringt Ihnen Nichtstun und Zuwarten nichts, also trauen Sie sich einfach, vorwärts zu machen!

Wie Sie wahrscheinlich leider schon wissen, …

Dieses Motto hat im richtigen Kontext und zur richtigen Zeit viel Gutes bewirkt. Es ist immer noch eine nützliche Heuristik für Ingenieure, wenn der Kontext klar ist.

Die Phrase wurde aber auch als Ausrede für eine Reihe von wesentlich schädlicheren Dingen verwendet.

Aus rein technischer Sicht war sie erfolgreich; sie führte zu zuverlässigen, schnellen Verbesserungen. Es kommt inzwischen immer seltener vor, dass sich Menschen in der Branche gegen rasche Rollouts wehren. Es kommt auch immer seltener vor, dass die grundlegenden Zuverlässigkeitsmechanismen (Versionskontrolle, kontinuierliche Integration, Unit-Tests) abgelehnt werden. Und viele ehemalige Facebook-Ingenieure haben dieses Motto in dem hier beschriebenen Sinne in die Welt hinaus getragen.

Aber bereits im Softwareentwicklungsumfeld selbst wird das Motto missbraucht: Es wurde mir schon als Begründung präsentiert, wieso ein Projekt keine Tests brauche; als Grund, dass ein Rollout trotz fehlender Zuverlässigkeitsmechanismen erzwungen wurde; als Ausrede, dass die Benutzer bei sie persönlich betreffenden Änderungen nicht informiert werden.

Ausserhalb dieses Bereichs sieht es noch viel schlimmer aus. Ein verbreitetes Missverständnis ist, dass überhaupt keine Zuverlässigkeitsmechanismen erforderlich seien, dass jede Änderung, die ein Softwareunternehmen vornehme, von Natur aus gerechtfertigt sei, weil es in Ordnung sei, „schnell zu handeln“. Wir sehen dies beispielsweise in der Art und Weise, wie es aus der Technik-Kultur von Facebook ausgebrochen ist und die gesamte Managementstrategie des Unternehmens durchdrungen hat, das von Markt zu Markt und von Problem zu Problem stolpert, katastrophale Fehler macht, sich oberflächlich entschuldigt und trotzdem weitermacht, alle möglichen Kollateralschäden ignorierend.

Seit einem Jahrzehnt ist es nicht mehr das offizielle Motto von Facebook. Trotzdem wird es immer noch verwendet, um unzählige Missstände in der Tech-Industrie zu verteidigen. Jeder Besucher der orangefarbenen Website sieht sofort, dass es immer noch so verwendet wird.

Selbst in seiner besten Form ist „schnell handeln und Dinge kaputt machen“ eine technische Heuristik, kein ethischer Grundsatz. Selbst in dem von mir beschriebenen Kontext ist es nur in Ordnung, schnell zu sein und Dinge zu gefährden. Es ist niemals in Ordnung, schnell zu sein und Menschen zu schaden.

Auch wenn «move fast and break things» zukünftig in der breiten Öffentlichkeit nicht mehr so missverstanden würde wie jetzt, würde ich den Spruch nicht mehr verwenden wollen. Stattdessen schlage ich folgende Formulierung vor:

«Arbeite gefahrloser, nicht langsamer.»

(Oder im Original: «Make it safer, not later.»)

Ende der Übersetzung «Safer, Not Later» von Glyph.

———

Weitere wichtige Schritte zur erfolgreichen Digitalisierung

Ich, Marcel Waldvogel, der Übersetzer der obigen Worte, hoffe, dass Sie die Essenz des Glyph’schen Essays mitgenommen haben:

Wir brauchen ein Sicherheitsnetz, damit wir rasch und gefahrlos arbeiten können. Auch (bzw. ganz besonders) in der Softwareindustrie.

Hier noch ein paar meiner Erfahrungen, wie wir dieses Sicherheitsnetz aufspannen können und wie wir danach das Hochseil eleganter und effizienter überqueren können. Mögen sie Ihre Softwareprojekte schneller, besser und gefahrloser machen.

Design

Einfach, übersichtlich, nutzbar

• Nicht mit der eierlegenden Wollmilchsau beginnen, sondern mit einem spezifischen Anwendungsfall, der konkret zu einer Verbesserung führt. Von da aus schrittweise vorgehen. (Oft als „Release early, release often“ formuliert ist es eigentlich nur eine konsequente Weiterführung von „Move fast and break things“.)
  Kein Wunder übrigens, dass eierlegende Wollmilchsäue schon lange vor den Dinosauriern ausgestorben sind.
• Wenn das Produkt auch für Einsteigerinnen bzw. seltene Nutzer nützlich sein soll (und das ist fast immer der Fall!): Die Benutzerführung auf deren Fall optimieren. Klar, verständlich, unnötige Felder/Fragen vermeiden oder nur bei Bedarf einblenden. Und für die Sonderfälle benutzerfreundliche Möglichkeiten vorsehen, deren Verarbeitung nicht unbedingt automatisiert sein muss („80/20-Regel„).
• Klare Trennung zwischen Frontend und Backend; dies vereinfacht Erweiterungen, Skalierung und Wartung.

Softwareentwicklung

Nachvollziehbar, automatisiert, sicher

• Den gesamten Quellcode und alle Zusatzinformationen (Grafiken, Übersetzungen, …) in unter Versionskontrolle (vorzugsweise git) ablegen. (Sollte heutzutage eigentlich eine Selbstverständlichkeit sein…)
• Automatisierte Tests auf jeder Stufe (Unit Tests, Integrationstests, Systemtests, Akzeptanztests, …). Man ist nicht schneller, wenn man Tests weglässt, auch nicht „nur am Anfang“, im Gegenteil (ausser vielleicht bei wirklich winzigen Projekten, aus denen garantiert(!) nie ein Produkt wird).
  Auch hier gilt: Je länger man das Unvermeidliche hinausschiebt, desto grösser ist der Gesamtaufwand.
• Automatisierungswerkzeuge wie Continuous Integration (CI), Continuous Delivery (CD), Infrastructure as Code (IaC), … Habe ich schon betont, wie wichtig Automatisierung ist?
• Sicherheit von Anfang an eine zentrale Rolle zukommen lassen, z.B. Unterstützung von 2FA und Single-Sign-On, defensive Programmierung, Nutzung von typsicheren, speichersicheren und Thread-sicheren Programmiersprachen, … (Und Sicherheit nicht als Add-On einplanen oder verkaufen!)
• Nicht zu viele neue Technologien ins Projekt einbringen (also, die im Projekt eingesetzten «Innovation Points» zu limitieren).

Betrieb

Monitoring, Dashboards, Backups

• Das System dauernd messen und beobachten. Bei Verhaltensänderungen sofort nachschauen («Monitoring» und «Dashboards» von oben).
• Alle Änderungen an den Daten protokollieren, damit ein Fehler isoliert und seine Auswirkungen rückgängig gemacht werden können (im einfachsten Falle können das die Transaktionslogs der Datenbank sein).
• Regelmässige Backups des Gesamtsystems und Tests, ob das System nach einem Hardware- oder Datenverlust wieder hochgefahren werden kann (Restore-Tests). Wenn sowieso alles automatisiert und unter Versionskontrolle ist — Continuous Integration/Continuous Delivery (CI/CD), Infrastructure-as-Code (IaC), … — besteht das Backup nur aus den eigentlichen Daten und ein grosser Teil der Restore-Tests finden quasi bei jeder Codeänderung statt.

Weiterführende Literatur

• Getting Real: The smarter, faster, easier way to build a successful web application, 37Signals/Basecamp, 2010-04-03 (auf Papier oder als kostenlose Webseite/PDF).
  Für mich das Standardwerk für die Denkweise hinter moderner Softwareentwicklung. Grundsätze zum Planen, Bauen und Vermarkten, an die man sich aber nicht dogmatisch halten muss.
• Derksen, Neggers, Onwezen und Zelen: Agile Secure Software Lifecycle Management: Secure by Agile Design, Secure Software Alliance, 2018.
  Ein Buch über Secure Software Development Lifecycle. Ich finde es nicht berauschend, kenne aber nichts Besseres, was in die Tiefe geht. Vorschläge werden gerne entgegen genommen!
• Prinzipien des Chaos Engineering, 2019-03.
  Ein Manifest über die Ziele des Chaos Engineering, einer Technik, um Systeme ausfallsicherer zu machen. [neu 2024-06-14]
• Drew Gallatin: The Magical Mystery Merge — Or — Why we run FreeBSD-current at Netflix (PDF), Openfest, 2023-11.
  Ein Erfahrungsbericht mit Beispielen, wie kurze Updatezyklen die Softwareentwicklung vereinfachen. [neu 2024-06-26]
• Mathew Duggan: A Eulogy for DevOps, 2024-06-28.
  Zeigt auf, dass wenn man zu viel Komplexität und zu wenig Koordination bzw. Arbeitsteilung „einfach so“ zusammenwürfelt, dass dann immer noch einiges schief gehen kann. Aufruf, dass komplexe Projekte immer noch viele und kompetente Leute aus verschiedenen Bereichen benötigt, die zusammenarbeiten können (und es auch tun). [neu 2024-06-30]
• Kristian Köhntopp: 1½ decades of Booking.com databases, Fediverse thread, 2024-08-02.
  Erfahrungen und Lessons learned aus dem Betrieb einer Applikation mit Tausenden von Datenbankservern. Auch wenn bei Ihnen eine Minute Downtime weniger als 15’000 Franken kostet: Viele der Erfahrungen gelten auf für kleinere Systeme, z.B. „wenn du auf die Maschine musst, um nachzuschauen, was läuft, machst du Monitoring falsch“ und „wenn du auf die Maschine musst, um etwas zu ändern, machst du Automatisierung falsch“. [neu 2024-08-02]
• Kristian Köhntopp: MySQL: Upgrading old MySQL instances, 2024-07-23.
  Weitere Lektion: „Sorge dafür, dass du jederzeit eine zusätzliche Replika zu deinem Datenbanksystem hinzufügen kannst. Egal zu welcher Tages- und Nachtzeit.“ (frei übersetzt). [neu 2024-08-02]
  

Bilder

Hier einige nützliche Grafiken, um die wichtigsten Punkte in Erinnerung zu behalten.