Dokumentation hat bei vielen keinen guten Ruf: zu aufwendig, zu trocken, zu weit weg vom eigentlichen Entwickeln. Häufig entsteht sie losgelöst vom Entwicklungsprozess, wird einmal geschrieben und danach kaum noch gelesen oder gepflegt. Statt ein lebendiger Teil des Produkts zu sein, veraltet sie stillschweigend.

Im agilen Manifest heißt es: „Working software over comprehensive documentation“, also „Funktionierende Software mehr als umfassende Dokumentation.“ Diese Aussage wird oft als Aufruf verstanden, Dokumentation zu vernachlässigen oder ganz wegzulassen. Doch war das wirklich die Intention? Oder geht es vielmehr um eine neue Art von Dokumentation – zur richtigen Zeit, mit dem richtigen Fokus?

In diesem Stream mit Ralf D. Müller und Liam Bergh geht es darum, wie Dokumentation im agilen Umfeld sinnvoll funktionieren kann: leichtgewichtig statt schwerfällig, integriert statt nachgelagert, hilfreich statt Pflichtübung. Es geht um Praxis, Haltung und konkrete Ansätze, um Teams durch Doku zu unterstützen, statt sie auszubremsen.

Livestream am 30. Januar

Die Ausstrahlung findet am Freitag, 30. Januar 2026, live ab 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.

(mdo)

Ein Team von namhaften Linux-Entwicklern hat sich zum Ziel gesetzt, Linux sicherer zu machen und die Integrität von Linux-Systemen kryptografisch zu verifizieren. Das Projekt sattelt unter anderem auf „immutable Linux“ auf, also schreibgeschützten, unveränderlichen Kernsystemen. Der Name: Amutable. Die Firma hat ihren Sitz in Berlin.

Große Namen sind als Gründer involviert. Etwa Lennart Poettering, der systemd entwickelt und pflegt, oder Christian Brauner, der das VFS-Subsystem in Linux betreut, sowie Christ Kühl, ehemals Gründer von Kinvolk – die Flatcar Container Linux, ein immutable-Linux-System, entwickelt haben und von Microsoft eingekauft wurden.

Überprüfbare Systemintegrität

Details liefert Amutable bislang nicht, deutet aber die Ziele an. Die Integrität des Systems soll kryptografisch prüfbar sein, das „System startet in einem verifizierten Status und bleibt im Zeitverlauf vertrauenswürdig“. Als Stichworte nennt die „Über“-Seite von Amutable die Integrität des Build-Prozesses, des Boot-Vorgangs und zur Laufzeit. Lennart Poettering hat bereits heiße Eisen mit „Measured Boot“ im Feuer. Ein Fingerzeig ist auch der geplante Vortrag „Remote Attestation of Imutable Operating Systems built on systemd“, den er am 12. März auf der Open Confidential Computing Conference in Berlin halten will.

Beim „Measured Boot“ prüft das System ausgehend von einer „Root of Trust“ im Trusted Platform Module (TPM) die Integrität von Firm- und Software beim Systemstart anhand von digitalen Fingerabdrücken, sogenannten Hash-Werten. Die Vergleichshashes liegen ebenfalls im TPM, dort in sogenannten Platform Configuration Registers (PCRs). Der Prozess ähnelt Secure Boot. Allerdings bricht Secure Boot bei abweichenden Hashes den Startvorgang ab, während Measured Boot die Hashes der Komponenten und ihrer Konfiguration protokolliert und sie verschlüsselt zur Überprüfung an andere Systeme senden kann (Remote Attestation, ausführliche Erläuterung von Infineon). Ein Vortrag auf der „All Systems Go“ im vergangenen Jahr zeigt zudem, was Poettering sich für Gedanken um die Sicherheitsarchitektur in Linux macht.

Derzeit besteht das Team von Amutable aus den Gründern Chris Kühl (CEO), Christian Brauner (CTO) und Lennart Poettering (Chief Engineer); Chief Product Officer ist David Strauss. Das Programmier-Team besteht aus Rodrigo Campos Catelin, Zbyszek Jędrzejewski-Szmek, Kai Lüke, Daan De Meyer, Joaquim Rocha, Aleksa Sarai und Michael Vogt. Die Beteiligten bringen Erfahrungen etwa für den Bau traditioneller Distributionen wie Debian, Fedora/CentOS, SUSE und Ubuntu mit, aber auch für unveränderliche, Image-basierte Distributionen wie Flatcar Container Linux, ParticleOS und Ubuntu Core, erklärt die Projekt-Ankündigung.

Kompetenzen für die genannten Ziele sind also reichlich vorhanden. Was genau Amutable aber bauen will, ist derzeit noch unklar. Eine diesbezügliche Anfrage wurde nicht umgehend beantwortet. Gegebenenfalls aktualisieren wir die Meldung damit.

(dmk)

Nicht nur in agilen Projekten gehört es zum normalen Vorgehen, Aufgaben zu schätzen (Ticket-Estimation). Persönlich vertrete ich dabei die Meinung, dass Schätzungen immer richtig sind. Es handelt sich schließlich um eine Schätzung.

Wikipedia versteht darunter die genäherte Bestimmung von Zahlenwerten, Größen oder Parametern durch Augenschein, Erfahrung oder statistische Methoden. Eine Schätzung bestimmt also etwas, was ist, und nicht etwas, was wird. Eine Schätzung kümmert sich nicht um die Zukunft.

Die meisten Manager, die ich erlebt habe, behandeln Schätzungen aber wie eine Prognose, also eine Vorhersage über die Zukunft.

Wenn die Zukunft dann zur Gegenwart geworden ist, vergleicht man die Schätzung aus der Vergangenheit mit einem Wert, der sich zu einem späteren Zeitpunkt entwickelt hat. Das passt nicht zusammen.

Was die Manager eigentlich wollen, ist – wie gesagt – eine Prognose. Auch dazu hat Wikipedia etwas Interessantes zu sagen: Von anderen Aussagen über die Zukunft (z. B. Prophezeiungen) unterscheiden sich Prognosen durch ihre Wissenschaftsorientierung.

Wer sich als Entwickler von Schätzungen und dem Umgang damit unter Druck gesetzt fühlt, kann mal versuchen, Schätzungen durch Prognosen zu ersetzen. Selbstverständlich explodiert damit der Aufwand. Und genau das ist der Punkt: Viele Manager sprechen sehr viel und sehr gerne darüber, wie man besser schätzen kann. In diese Frage wird viel Energie gesteckt. Die Frage, wie man besser arbeiten kann, tritt dabei oft in den Hintergrund.

Es wirkt manchmal so, als ob die Schätzung (die eigentlich eine Prognose sein soll) wichtiger als das Produkt ist. Der Grund dahinter ist oft die den Managern heilige Planung. Die Gründe für deren Scheitern liegen aber nicht in der Durchführung der Schätzung. Eine Schätzung ist immer richtig, wie ich auch bereits an anderer Stelle schrieb.

Das gilt auch, wenn der geschätzte Wert vom wahren Wert abweicht. Wenn mir das nicht gefällt, müsste ich eine Schätzung durch eine Messung ersetzen. Das ist in diesem Fall nicht möglich, weil ich zukünftige Ergebnisse nicht heute messen kann.

Wenn ein Ticket bei Fertigstellung also dreimal so viel Zeit erforderte, wie geschätzt (prognostiziert) wurde, wird nicht die Frage gestellt, ob die Umsetzung des Tickets gut gelaufen ist. Nein. Bereits die Abweichung von der Schätzung (Prognose) genügt, um die geleistete Arbeit zu diskreditieren. Das halte ich für wenig zielführend, und hier sind meines Erachtens Softwareentwickler aufgefordert, der missbräuchlichen Verwendung von Schätzungen entgegenzutreten.

Der erste Schritt kann darin bestehen, klarzumachen, dass Pläne auf Grundlage von Schätzungen selbst Schätzungen und keine Zusagen sind. Wer es anders sieht, dem kann man mit hoher Wahrscheinlichkeit eine turbulente Zukunft prophezeien.

Erst Lesen, dann Handeln

Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung. Sie wirkt auch ohne Führungsposition. Mit dem Code „heisedev“ gibt’s den Heise-Rabatt für Interactive-Members.

(rme)