Rückblick auf unseren TechTalkThursday #25

Unser dritter TechTalkThursday im Jahr 2025 – es war schon die 25. Ausgabe unserer Eventreihe – fand am 4. September 2025 um 18 Uhr in unserem Büro am Stauffacher in Zürich statt. Wir durften drei externe Speaker*innen willkommen heissen, die allesamt spannende Vorträge hielten. Viele Leute waren vor Ort mit dabei, darunter auch einige interessierte Nine-Mitarbeitende, einige Gäste der Referent*innen und viele externe Teilnehmende, die sich für die Themen Technical Debt, Infrastruktursorgen bei Softwarefirmen und NixOS interessierten.

Der Abend wurde auch live auf unserem YouTube-Kanal gestreamt und wir haben uns gefreut, dass auch einige Zuschauer auf dieser Plattform dabei waren. Wie üblich eröffnete Thomas Hug, unser CEO und Gründer der Firma, die Veranstaltung mit einer kurzen Einführung, in der er die Agenda des Abends vorstellte, die Referierenden präsentierte und die Themen ihrer Vorträge zeigte. Diesmal waren die drei Referent*innen Patrick Scheller, Lukas Lehmann, Mitgründer der Pupil AG, und Lena Fuhrimann, Gründerin von bespinian.

Technische Schulden: Wie man sie erkennt und wie man damit umgeht

Patricks Vortrag war der erste des Abends und befasste sich mit der unvermeidlichen Realität technischer Schulden in der Softwareentwicklung, warum sie entstehen und wie Teams effektiv damit umgehen können.

Er betonte zunächst, dass technische Schulden nicht beseitigt werden können. Jede Entscheidung in der Entwicklung beinhaltet Kompromisse zwischen Geschwindigkeit, Qualität und Wartbarkeit. Selbst die besten Teams und Unternehmen häufen Schulden an, da geschäftlicher Druck, Termine und konkurrierende Prioritäten unvermeidlich technische Entscheidungen beeinflussen. Technische Schulden sind daher nicht nur ein technisches Problem, sondern eine strategische Geschäftsentscheidung: Manchmal akzeptieren Unternehmen bewusst Schulden, um schneller zu liefern oder andere Ziele zu priorisieren.

Patrick hat die Ursachen für technische Schulden in drei Hauptbereiche unterteilt:

Code & Architektur – Mangelhafte Tests, unzureichende Dokumentation, ignorierte Codeüberprüfungen und ungelöste Fehler tragen dazu bei. Ohne Kontrollen und Gegenkontrollen arbeiten Teams «blind» und lassen Fehler anhäufen, bis sie zu gröberen Problemen führen.
Projekt- & Prozessmanagement – Unzureichende Planung, schwache Anforderungsanalyse, Scope Creep und schlechte Priorisierung können die Projektergebnisse untergraben. Kommunikationsfehler verschärfen Missverständnisse, was Nacharbeiten und vergebliche Anstrengungen erforderlich macht.
Menschen & Wissen – Mangelnde Erfahrung, schlechter Wissensaustausch, geringe Motivation, Reibungen im Team und hohe Fluktuation verringern den Zusammenhalt und verlangsamen den Fortschritt. Ein Mangel an Eigenverantwortung oder die Nichtübernahme neuer Praktiken verschärfen das Problem zusätzlich.

Diese Faktoren stehen in Wechselwirkung mit dem «Projektmanagement-Dreieck» aus Zeit, Umfang und Kosten. Die Anpassung eines Faktors wirkt sich unweigerlich auf die anderen aus und technische Schulden verstärken diese gegenseitige Abhängigkeit. So führt beispielsweise eine Investition von mehr Zeit und Budget möglicherweise nicht zu proportionalen Qualitätsverbesserungen, wenn Wissenslücken oder eine schlechte Architektur bestehen bleiben.

Um diesen Herausforderungen entgegenzuwirken, hob Patrick die Bedeutung von Messung und Überwachung hervor. Teams sollten das Aufgabenvolumen, die Genauigkeit der Schätzungen, die Vorlaufzeit von der Definition der Funktionen bis zur Lieferung, die mittlere Reparaturzeit (MTTR), die Fehlerquote und die Trends bei der Wartbarkeit verfolgen. Solche Kennzahlen, die über einen längeren Zeitraum beobachtet werden, zeigen, ob sich die Schulden erhöhen oder ob sie unter Kontrolle sind.

Auf praktischer Ebene schlug er Folgendes vor:

Regelmässige Aktualisierung von Bibliotheken, Tools und Sprachversionen, um die Angst vor Upgrades und deren Komplexität zu verringern
Durchführung von «Proximity-Updates» (kleine Verbesserungen in verwandten Code-Bereichen, wenn dort bereits gearbeitet wird)
Planung kleiner Refactorings für jeden Sprint, während grosse Refactorings sorgfältig geplant werden
Verwendung von Mustern wie dem Strangler- oder Backend-for-Frontend-Ansatz (BFF), um Systeme schrittweise zu modernisieren

Ein weiteres entscheidendes Element ist es, den Stakeholdern Refactoring und Schuldenabbau «schmackhaft zu machen». Entwickler können nicht einfach für saubereren Code argumentieren, sondern müssen die Vorteile in einer Weise darstellen, die für die verschiedenen Zielgruppen relevant ist. Führungskräfte interessieren sich für Kosten und Risiken, Projektmanager konzentrieren sich auf Liefergeschwindigkeit und Stabilität, und Entwickler legen Wert auf Wartbarkeit. Die Präsentation von Daten und Trends stärkt die Argumentation und hilft, Zeit und Budget für den Schuldenabbau zu sichern.

Patrick schloss seine Präsentation mit der Feststellung, dass alle Systeme technische Schulden haben. Der Schlüssel liegt nicht in der Beseitigung, sondern im kontinuierlichen Management: schrittweise daran arbeiten, strategische Prioritäten setzen und eine übermässige Anhäufung verhindern. Das Ignorieren erhöht nur die «Zinsen», die Teams später in Form von langsameren Lieferungen, mehr Fehlern und geringerer Flexibilität zahlen müssen.

Letztendlich behandeln erfolgreiche Unternehmen technische Schulden als einen unvermeidlichen Teil der Softwareentwicklung, der jedoch aktiv überwacht, verwaltet und auf allen Ebenen des Unternehmens kommuniziert werden muss.

Warum Softwareunternehmen aufhören sollten, sich um die Infrastruktur zu sorgen

Im zweiten Vortrag skizzierte Lukas von der Pupil AG den Werdegang des Unternehmens von einem kleinen MVP für die Schulverwaltung zu einem schnell wachsenden Schweizer EdTech-Anbieter und erklärte, warum Softwareunternehmen ihren Fokus eher auf Software als auf Infrastruktur legen sollten.

Pupil entstand, als ein Lehrer, frustriert von ineffizienten Schulprozessen, ein kleines PHP/MySQL-Tool entwickelte. Es wurde zunächst in einer Schule getestet, verbreitete sich jedoch schnell, was 2019 zur offiziellen Gründung des Unternehmens führte. Die frühe Finanzierung ermöglichte die Einstellung qualifizierter Entwickler und stellte Ressourcen zur Verfügung, um die langen Verkaufszyklen öffentlicher Schulen zu bewältigen. Der Durchbruch gelang Pupil mit der Zulassung im Kanton Thurgau im Jahr 2020, gefolgt von öffentlichen Ausschreibungen in St. Gallen (2021), Schwyz (2022) und Aargau (2023). Diese Erfolge positionierten das Unternehmen als führende digitale Lösung für K-12-Schulen in der Schweiz.

Pupil bietet eine All-in-One-Cloud-basierte Schulverwaltungsplattform, die Prozesse wie das Drucken von Zeugnissen, die Verwaltung von Schüler- und Elterndaten, die Geräteintegration, den Nachrichtenversand und die Kommunikation mit den Eltern zusammenfasst. Bisher verwendeten Schulen drei bis fünf separate Tools, was zu Ineffizienz und Datensilos führte. Durch die modulare Einführung – Schulen können beispielsweise mit dem Messaging beginnen und später erweitern – vereinfacht Pupil digitale Arbeitsabläufe und behält dabei den klaren Fokus auf K-12. Die Eingrenzung des Anwendungsbereichs vermeidet unnötige Komplexität und technische Schulden, ein häufiges Risiko, wenn man versucht, einen zu breiten Markt zu bedienen.

Laut Lukas lief Pupil in der Anfangszeit auf einigen wenigen Linux-VMs, die zwar kostengünstig, aber nur begrenzt skalierbar waren. Mit zunehmender Verbreitung wurde diese Konfiguration jedoch unzureichend. Das Unternehmen diskutierte einen Wechsel zu Microservices, entschied sich jedoch stattdessen für eine domänengesteuerte hexagonale Architektur innerhalb einer einzigen Codebasis, die Modularität und Wartbarkeit in Einklang bringt. Dieser Ansatz unterstützt ein Team von mehr als 30 Entwickler*innen, ohne dass der Aufwand für die Verwaltung Dutzender Microservices entsteht.

Die wichtigste Erkenntnis für das Unternehmen war, dass Kunden sich nicht für Infrastrukturdetails interessieren. Schulen interessieren sich nur für Datenschutz, Zuverlässigkeit, Leistung und neue Funktionen – nicht dafür, ob das System «cloud-nativ» ist oder den neuesten Architekturtrends folgt. Wie Lukas es analogisierte, interessiert es Restaurantgäste nicht, ob die Speisen auf Gas oder Induktion zubereitet werden – sie interessieren sich für das Essen.

Anstatt die Infrastruktur neu zu erfinden, hat Pupil eine Partnerschaft mit uns für Managed Cloud Services geschlossen und ist von einzelnen VMs auf Kubernetes-basierte Bereitstellungen umgestiegen. Dadurch konnte die Einrichtungszeit für eine neue Schule von mehreren Stunden auf wenige Minuten reduziert werden, und das vollständig automatisiert. Das DevOps-Team, das aus nur zwei Personen besteht, nutzt Managed Services, wo immer dies möglich ist, um den Aufwand zu minimieren.

Wie René, ein Kollege von Lukas und DevOps-Engineer, erklärte, betreibt Pupil Produktions- und Testsysteme getrennt voneinander, um Kundendaten zu schützen. Jeder Schulmandant erhält einen eigenen Kubernetes-Namespace mit dedizierten PHP- und Nginx-Containern, Datenbanken mit Failover und persistenter Speicherung (mit Übergang zu S3). Die Überwachung erfolgt mit Grafana und entsprechenden Tools von Nine. Die Architektur ermöglicht Sharding über Cluster hinweg (z. B. 300 Schulen pro Cluster) für Skalierbarkeit.

Lukas betonte, dass der geschäftliche Wert in der Software und den Kundenfunktionen liegt, nicht im Aufbau einer massgeschneiderten Infrastruktur. Das Unternehmen legt Wert auf Einfachheit («keep it simple, stupid») und setzt auf Managed Services, um effizient zu skalieren. Regulatorische Anforderungen wie ISO-Zertifizierungen beschränken den Zugriff auf Produktionsumgebungen und gewährleisten so Sicherheit bei gleichbleibender Entwicklungsgeschwindigkeit. Die Entwicklung von Funktionen wird sowohl von Kundenanforderungen als auch von den Prioritäten des Produktmanagements vorangetrieben, wobei die unterschiedlichen Bedürfnisse der Schulen in den verschiedenen Kantonen berücksichtigt werden.

Die Geschichte von Pupil zeigt, dass die Infrastruktur Softwareunternehmen nicht von ihrer eigentlichen Aufgabe ablenken sollte: der Schaffung von Kundennutzen. Durch die Auslagerung von Infrastrukturbelangen, die Vereinfachung der Architektur und die Konzentration auf die Bedürfnisse von K-12-Schulen ist Pupil schnell gewachsen und hat gleichzeitig Kosten, Risiken und Komplexität unter Kontrolle gehalten.

NixOS: Wie mein Laptop deklarativ wurde

In ihrem Vortrag, dem letzten des Abends, berichtete Lena von ihrem persönlichen Weg vom Experimentieren mit Arch Linux hin zu NixOS und erklärte, wie der deklarative Ansatz von Nix die Art und Weise verändert hat, wie sie ihren Laptop und ihre Entwicklungsumgebungen verwaltet.

Zu Beginn ihrer Karriere nutzte Lena Arch Linux und schätzte dessen Flexibilität, musste jedoch immer wieder Software manuell installieren, deinstallieren und neu konfigurieren. Dies stand in starkem Kontrast zu ihrer Arbeit mit Containern, bei der eine Dockerfile eine deklarative Spezifikation der Umgebung lieferte – vollständig reproduzierbar und portabel. Um diese Lücke zu schliessen, schrieb sie zunächst ein kleines Tool namens Pacman-file, mit dem sie die gewünschten Pakete deklarativ auflisten konnte. Das Tool war zwar nützlich, deckte jedoch nur die Installation von Paketen ab, nicht aber Systemdienste, Konfigurationen oder Designs.

Anschliessend experimentierte sie mit GNU Stow, um Konfigurationsdateien aus einem Git-Repo zu verwalten, was die Reproduzierbarkeit ihres Home-Verzeichnisses verbesserte. Dennoch fehlte dem Betriebssystem selbst eine deklarative Verwaltung. Der Wendepunkt kam, als sie Nix entdeckte, das eine deklarative, reproduzierbare und zuverlässige Konfiguration ganzer Systeme ermöglicht, von Laptops bis hin zu Cloud-Servern.

Fuhrimann zeigte, dass Nix drei Dinge ist:

Ein Paketmanager (2003 als Doktorandenprojekt entwickelt), der unter Linux und macOS installiert werden kann. Seine Ziele sind Reproduzierbarkeit, Deklarativität und Zuverlässigkeit. Nix isoliert Abhängigkeiten und verhindert so Konflikte, die bei anderen Paketmanagern häufig auftreten.
Eine funktionale Programmiersprache, die zur Definition von System- und Paketkonfigurationen verwendet wird. Sie ist rein und idempotent – bei gleicher Konfiguration liefert sie immer das gleiche Ergebnis. Deklarativität bedeutet, den gewünschten Zustand zu spezifizieren, nicht die Schritte, um ihn zu erreichen.
Ein Betriebssystem (NixOS), bei dem alles, von Systemdiensten bis zur Desktop-Umgebung, in Konfigurationsdateien deklariert werden kann. NixOS unterstützt sowohl stabile als auch rollierende Releases, atomare Upgrades und System-Rollbacks, wodurch es widerstandsfähig gegen Fehler ist.

Der Nix-Store untermauert die Reproduzierbarkeit. Installierte Pakete und Abhängigkeiten werden mit eindeutigen Hashes gespeichert, sodass mehrere Versionen von Software (z. B. verschiedene GCC-Versionen) ohne Konflikte nebeneinander existieren können. Rollbacks und Validierungsmechanismen sorgen für zusätzliche Ausfallsicherheit, während regelmässige Bereinigungen eine unbegrenzte Festplattennutzung verhindern.

Lena demonstrierte, wie durch Hinzufügen einer einzigen Zeile zu ihrer Konfigurationsdatei neue Dienste – zum Beispiel die Ausführung der n8n-Automatisierung – aktiviert werden können. Das System löst automatisch Abhängigkeiten auf, richtet Dienste ein und wendet Änderungen atomar an. Nix kann auch Benutzerumgebungen deklarativ konfigurieren, von Editoren wie Neovim bis hin zu Desktop-Themes.

Nix hat sich zu einer der aktivsten Open-Source-Communities auf GitHub entwickelt, mit einem Repository von über 120.000 aktuellen Paketen – mehr als Arch’s AUR oder Homebrew. Konferenzen wie NixCon und lokale Meetups fördern die Zusammenarbeit. Das Ökosystem umfasst auch Tools wie Disco für die deklarative Festplattenverschlüsselung und -partitionierung.

Vorteile von NixOS:

Deklarativer OS-as-Code-Ansatz
Hohe Reproduzierbarkeit und keine Abhängigkeitskonflikte
Atomare Upgrades mit Rollback-Unterstützung
Möglichkeit, Entwicklungsumgebungen teamübergreifend zu definieren und zu teilen
Grosse, aktive Community und Ökosystem

Nachteile:

Steile Lernkurve, insbesondere für diejenigen, die an traditionelle Linux-Distributionen gewöhnt sind
Inkonsistente Dokumentation trotz Community-Aktivitäten
Einige Funktionen sind noch experimentell
Erhöhter Festplattenspeicherbedarf aufgrund mehrerer Paketversionen
Gelegentliche kryptische Fehlermeldungen und mangelnde strikte Einhaltung des Filesystem Hierarchy Standard (FHS)

Lena kam zu dem Schluss, dass NixOS keine Wunderwaffe ist, sondern einen starken Paradigmenwechsel hin zur Behandlung von Laptops und PCs als deklarativ definierte Infrastruktur darstellt. Trotz der Herausforderungen machen die Vorteile der Reproduzierbarkeit, Modularität und Zuverlässigkeit es für Entwickler, die bereit sind, in das Lernen zu investieren, attraktiv. Zu guter Letzt ermutigte sie das Publikum, mit NixOS zu experimentieren und sich der lebendigen Community anzuschliessen.