«Move fast and break things» richtig verstehen und nutzen

«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 bei DNIP auch auf Deutsch: Für alle, die besser verstehen wollen, wie Software heute entsteht und was das für Digitalisierung bedeutet.

Das Titelbild ist eine Collage aus Ming-Vase von MicKennei KAGMOIRZ (CC BY-SA 4.0) und eigenem Foto einer Lightning-McQueen-Replika aus der besuchenswerten Enter Technikwelt.

Die Essenz des Glyph-Essays

Das Wichtigste, was Sie aus dem Glyph-Essay (Original oder deutsche Übersetzung) mitnehmen sollten:

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.

Gute Softwareentwicklung

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!

Bilder

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