«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.
Aktuelles zu IT-Sicherheit
- Sicherheit versteckt sich gerne
Wieso sieht man einer Firma nicht von aussen an, wie gut ihre IT-Sicherheit ist? Einige Überlegungen aus Erfahrung. - Chatkontrolle: Schöner als Fiktion
Wir kennen «1984» nicht, weil es eine technische, objektive Abhandlung war. Wir erinnern uns, weil es eine packende, düstere, verstörende Erzählung ist. - Chatkontrolle, die Schweiz und unsere Freiheit
In der EU wird seit vergangenem Mittwoch wieder über die sogenannte «Chatkontrolle» verhandelt. Worum geht es da? Und welche Auswirkungen hat das auf die Schweiz? - Cloudspeicher sind nicht (immer) für die Ewigkeit
Wieder streicht ein Cloudspeicher seine Segel. Was wir daraus lernen sollten. - IT sind nicht nur Kosten
Oft wird die ganze IT-Abteilung aus Sicht der Geschäftsführung nur als Kostenfaktor angesehen. Wer das so sieht, macht es sich zu einfach. - CrowdStrike, die Dritte
In den 1½ Wochen seit Publikation der ersten beiden Teile hat sich einiges getan. Microsoft liess es sich nicht nehmen, die Schuld am Vorfall der EU in die Schuhe zu schieben, wie das Apple mit ihrer KI ja auch schon frech versuchte. Andererseits haben die Diskussionen zum Vorfall viele Hinweise darauf gegeben, wie IT-Verantwortliche ihre… CrowdStrike, die Dritte weiterlesen - Unnützes Wissen zu CrowdStrike
Ich habe die letzten Wochen viele Informationen zu CrowdStrike zusammengetragen und bei DNIP veröffentlicht. Hier ein paar Punkte, die bei DNIP nicht gepasst hätten. Einiges davon ist sinnvolles Hintergrundwissen, einiges taugt eher als Anekdote für die Kaffeepause. - Marcel pendelt zwischem Spam und Scam
Beim Pendeln hatte ich viel Zeit. Auch um Mails aus dem Spamordner zu lesen. Hier ein paar Dinge, die man daraus lernen kann. Um sich und sein Umfeld zu schützen. - Die NZZ liefert Daten an Microsoft — und Nein sagen ist nicht
Die andauernden CookieBanner nerven. Aber noch viel mehr nervt es, wenn in der Liste von „800 sorgfältig ausgewählten Werbepartnern (oder so)“ einige Schalter fix auf „diese Werbe-/Datenmarketingplattform darf immer Cookies setzen, so sehr ihr euch auch wehrt, liebe User“ eingestellt sind und sich nicht ändern lassen. Da fühlt man sich gleich so richtig ernst genommen.… Die NZZ liefert Daten an Microsoft — und Nein sagen ist nicht weiterlesen - «CrowdStrike»: Ausfälle verstehen und vermeiden
Am Freitag standen in weiten Teilen der Welt Millionen von Windows-Rechnern still: Bancomaten, Lebensmittelgeschäfte, Flughäfen, Spitäler uvam. waren lahmgelegt. Die Schweiz blieb weitgehend nur verschont, weil sie noch schlief. Ich schaue hinter die Kulissen und zeige auf, was wir tun müssen, damit dies nicht nochmals passiert. Leider betrifft uns das alle. - Auch du, mein Sohn Firefox
Ich habe bisher immer Firefox empfohlen, weil seine Standardeinstellungen aus Sicht der Privatsphäre sehr gut waren, im Vergleich zu den anderen „grossen Browsern“. Das hat sich geändert. Leider. Was wir jetzt tun sollten. - «Voting Village»-Transkript
Letzten August fand an der Hackerkonferenz DEFCON eine Veranstaltung der Election Integrity Foundation statt. Sie fasste mit einem hochkarätigen Podium wesentliche Kritikpunkte rund um eVoting zusammen.
Schreibe einen Kommentar