Keine Silver Bullets – außer Continuous Delivery?

Inhaltsverzeichnis

Eigentlich gibt es keine "Silver Bullets". Aber Continuous Delivery verspricht so viele Vorteile, dass es ein solches Silver Bullet sein könnte. Was stimmt also: Gibt es sie doch oder ist Continuous Delivery überbewertet?

Der Ausdruck "Silver Bullet" kommt von einem Paper aus dem Jahr 1986 von Frederick Brooks. Dieser ist Autor des Buchs "The Mythical Man-Month", das über die Entwicklung von IBMs OS/360-Betriebssystem berichtet. Er hat dieses Projekt geleitet. Es hatte ein Budget von 5 Milliarden US-Dollar und wurde in den Sechzigern nur durch die Mondlandung in den Schatten gestellt. Das Buch enthält Erkenntnisse, die auch heute noch wichtig sind – beispielsweise dass ein Projekt zunächst langsamer wird, wenn man mehr Personen mit dem Projekt betraut, weil die Personen sich erst mal einarbeiten müssen.

Silberkugeln

Silberkugeln dienen eigentlich zur Jagd auf Werwölfe. Brooks argumentiert, dass viele IT-Projekte irgendwann zu einem Monster mutieren und wir daher Silberkugeln brauchen. Die gibt es aber nicht: Seiner Meinung nach verspricht keine einzelne Entwicklung in einem Jahrzehnt eine Größenordnung bessere Produktivität, Zuverlässigkeit oder Einfachheit. Eine Größenordnung ist ein Faktor von 10.

Brooks argumentiert, dass die technischen Komplexitätstreiber bereits eliminiert sind. Wenn aber die meiste Komplexität mittlerweile durch die Anforderungen, Designs und Tests entstehen, kann man die Komplexität nicht einfach durch einen einfachen Trick lösen. Vielversprechend findet er das Kaufen, statt irgendwas selbst zu bauen, besserer Umgang mit Anforderungen, das "Züchten" von Software durch inkrementelle Entwicklung und schließlich gute Designer.

Continuous Delivery

Continuous Delivery bezeichnet das kontinuierlich Ausliefern von Software. Es ist klar, dass durch eine höhere Deployment-Frequenz die Zeit abnimmt, bis eine Änderung in Produktion ist. Mittlerweile gibt es eine Studie ("2018 State of DevOps Report"), die weitere Effekte aufzeigt. Sie unterscheidet "Elite Performer", die nach Bedarf mehrmals pro Tag deployen, und "Low Performer", die zwischen einmal pro Woche und einmal pro Monat deployen. Teams mit Quartalsreleases sind also noch nicht einmal "Low Performer.

Elite-Performer erreichen logischerweise höhere Geschwindigkeit, mit denen Änderungen in Produktion gelangen:

• Die Deployment-Frequenz ist um den Faktor 46 höher.
• Die Zeit, bis eine Änderung in Produktion geht, ist um den Faktor 2555 geringer.

Aber es gibt auch andere positive Effekte:

• Die Wahrscheinlichkeit, dass Deployments fehlschlagen, ist siebenfach geringer.
• 2604fach schnelleres Wiederanlaufen nach dem Ausfall eines Services.
• 2/3 mehr Arbeitszeit kann für neue Features aufgewendet werden.
• Halb so viel Arbeitszeit ist für Sicherheitsprobleme oder Defekte aufzuwenden, die von Endbenutzern gemeldet werden.
• Man braucht nur ein Drittel der Zeit für Kunden-Support.

Also steigen Produktivität und Zuverlässigkeit. Continuous Delivery könnte demnach eine "Silberkugel" sein, obgleich es sie nach Brooks ja nicht geben dürfte. Wie kann dieser Widerspruch geklärt werden?

Doch Silberkugeln?

Eine Erklärung könnte sein, dass Brooks nicht recht hat. Zu beweisen, dass etwas nicht existiert, ist prinzipiell schwierig. Sein Paper nennt keine Belege, sondern gibt im Wesentlichen die Meinung des Autors wieder. Es ist mittlerweile 30 Jahre alt, sodass sich vielleicht mittlerweile etwas geändert hat.

Auf der anderen Seite ist Brooks sehr erfahren und eine der wichtigsten Personen in der Softwareentwicklungsszene. Also kann man das Paper nicht so ohne weiteres ignorieren.

Continuous Delivery – nur ein Hype?

Die genannte Studie könnte auch fehlerhaft sein. Hinter der Studie steht Gene Kim, der unter anderem das DevOps-Handbuch und das Buch über das Phoenix-Projekt geschrieben hat. Beides Bücher, die Continuous Delivery positiv sehen. Ein weiterer Protagonist der Studie ist Jez Humble, einer der Autoren des ersten Continuous-Delivery-Buchs. Es wäre erstaunlich, wenn diese Personen eine Studie schreiben, die zeigt, dass Continuous Delivery doch keine erheblichen Vorteile bringt.

Aber die dritte Autorin im Bunde ist die Wissenschaftlerin Dr. Nicole Forsgren. So kann man sicher sein, dass die Studie einer wissenschaftlichen Überprüfung standhält und entsprechend wissenschaftlicher Standards ausgewertet worden ist. Und schließlich kann die Studie eine große Datenbasis vorweisen: Insgesamt haben 30.000 Personen an ihr teilgenommen. Eine große Datenbasis und eine professionelle Auswertung der Daten führt eigentlich zu aussagekräftigen Ergebnissen.

Beides stimmt?

Ich glaube, dass es gar keinen Widerspruch gibt. Die Studie und Brooks haben beide recht.
Dafür gibt es mehrere Gründe:

• Das Erhöhen der Deployment-Geschwindigkeit ist keine "einzelne Entwicklung". Durch das Beschleunigen des Deployments müssen Konfigurationsmanagement, Tests, Deployments und die Genehmigung von Änderungen automatisiert werden. Das zeigt die Studie auch auf. Oft gehen die Änderungen bis in die Architektur. Nur kleine, getrennt deploybare Einheiten wie Microservices sind realistisch mehrmals pro Tag deploybar. Höhere Deployment-Geschwindigkeit kann also auf die Herausforderungen hinweisen, die gelöst werden müssen, um noch schneller zu deployen. Aber es ist keine "einzelne Entwicklung", sondern erfordert eine Vielzahl an Maßnahmen.
• Brooks schließt eine Verbesserung um eine Größenordnung in Produktivität, Zuverlässigkeit oder Einfachheit aus. Die Studie sieht aber "nur" eine Verbesserung von 2/3 bei Produktivität, wenn man die Arbeitszeit für neue Features als Maß dafür nutzt. Bei der Zuverlässigkeit ist es ein Faktor zwei, wenn man die Arbeitszeit betrachtet, die zum Beseitigen von Fehlern benötigt wird. Die Wahrscheinlichkeit, dass ein Deployment zu einem Fehler führt, ist um den Faktor sechs niedriger – aber auch das ist keine Größenordnung.
• Schließlich setzt Continuous Delivery das von Brooks empfohlene "Züchten" von Software um: Software wird öfter in Produktion gebracht. Daher gehen die Teams in kleineren Schritten vor. Das begünstigt Feedbackzyklen: Ergebnisse aus der Produktion können sofort in die Entwicklung einfließen und so kann das Projekt schrittweise wachsen statt nach einem komplexen Plan fertiggestellt zu werden.

Fazit

Continuous Delivery hat tatsächlich viele deutliche Vorteile. Die Studie zeigt diese klar und sehr gut belegt auf. Das hilft dabei, die Vorteile von Continuous Delivery eindeutig darzustellen. Dennoch ist auch Continuous Delivery wohl nicht das Silver Bullet. Dennoch gehen die Vorteile von Continuous Delivery weit über das schnelle Ausliefern von Software und neuen Features hinaus. Es lohnt sich also, in diesen Bereich zu investieren, selbst wenn nicht schneller Features in Produktion gebracht werden müssen, weil auch Produktivität und Zuverlässigkeit signifikant besser werden.

tl;dr

Silver Bullets sollen Softwarentwicklung um mindestens eine Größenordnung verbessern, aber es gibt leider keine. Continuous Delivery hat dennoch nachweisbare erhebliche Vorteile auch für Zuverlässigkeit und Produktivität. ()