Warum wir uns mit lokalen Build-Zeiten beschäftigen sollten

Was ist die Haupttätigkeit von Entwickler_innen? Warten. Was wie ein schlechter Scherz klingt, ist leider keiner. Die Realität ist, dass Entwickler_innen immer wieder auf Dinge warten müssen – zum Beispiel auf den lokalen Build.

Das Problem

Software wird immer komplexer, die Codebasis größer – Builds dauern länger. Gleichzeitig wird der Druck immer höher, schneller zu releasen. Das Bottleneck “Build-Zeiten” wird deswegen immer relevanter.

Oben kurz angerissen, hier noch einmal zusammengefasst die Gründe, warum es zu langen Build-Zeiten kommt:

Rechenleistung des Computers: Computer mit veralteter oder schlechter Hardware können die Build-Zeit verlangsamen.
Größe des Projekts: Größere Softwareprojekte mit vielen Dateien und Komponenten benötigen in der Regel mehr Zeit, um kompiliert zu werden.
Abhängigkeiten: Wenn die Software von anderen Bibliotheken oder Komponenten abhängt, müssen diese ebenfalls integriert werden.
Änderungsumfang: Wenn es viele Codeänderungen gibt, kann das mehr Zeit in Anspruch nehmen.
Fehler und Probleme: Wenn während des Build-Prozesses Fehler auftreten, müssen diese behoben werden, bevor der lokale Build erfolgreich erstellt werden kann. Die Zeit für das Auffinden und Beheben von Fehlern kann variieren.

Doch welche Auswirkungen hat eine lange Build-Zeit?

Steven Lemons beschreibt das Problem in seinem Beitrag auf Medium besonders greifbar. Die Wartezeit auf Builds kann in drei Kategorien gegliedert werden.

Kategorie	Beschreibung
Kurze Wartezeit	Unaufdringlich; Es kann sofort ohne Unterbrechung weitergearbeitet werden.
Mittlere Wartezeit	Wahrnehmbar; Der momentane Gedankengang wird unterbrochen.
Lange Wartezeit	Frustrierend; Es wird sich anderweitig beschäftigt.

Je länger also die Wartezeit, desto wahrscheinlicher, dass etwas anderes gemacht wird. Ein ganz normaler Prozess, der nachvollziehbar ist. Jede_r kann das bei einem Websiteaufruf gut beobachten. Lädt eine Seite zu lange, wird der Tab geschlossen und eine Alternative probiert.

Bei einem Websiteaufruf gibt es allerdings einen Unterschied: Wir können sofort eine Seite aufrufen, die ebenso relevant ist und uns zu unserem Ziel führt. Der Task, den wir bearbeiten, bleibt gleich.

Entwickler_innen sind allerdings bei langen Wartezeiten dazu genötigt, entweder etwas anderes zu tun (Task wechseln), oder die Wartezeit anders zu überbrücken (Auch Memes-Seiten sind hier sehr beliebt ;)).

Das führt zu mehreren Problemen:

Betriebswirtschaftlich gesprochen verringert sich die Produktivität. Ressourcen werden ineffizient eingesetzt. Wie viel langsame Builds tatsächlich kosten (Hint: eine Menge!) haben wir in dem Beitrag “Die Kosten von langen Build-Zeiten” genau aufgeschlüsselt. Auf individueller Ebene führt eine lange Build-Zeit zu Frustration. Durch das ständige Warten konzentrieren sich Entwickler_innen auf mehrere Tasks, müssen sich ständig in neue Aufgaben einarbeiten und machen mehr Fehler. Wird die Wartezeit genutzt, um andere Sachen zu erledigen, wird vielleicht sogar übersehen, dass der andere Task eigentlich noch bearbeitet werden muss. Am Ende des Tages kostet das alles Energie.

Brett Schuchert spricht in diesem Kontext von weiteren versteckten Kosten, die aber selten gemessen werden uns sich in Form von längeren Bearbeitungszeiten von Tasks, Arbeitszeiten und einer höheren Fluktuation bemerkbar machen. Untermauert werden all diese Faktoren von einer stackoverflow-Studie: “Being productive” wird als eine der wichtigsten Einflüsse genannt, die Developer am Arbeitsplatz glücklich machen.

Viel zu oft wird dieses Problem auch einfach akzeptiert und hingenommen. Das sollte nicht so sein.

Die Lösung

Es geht auch anders. LinkedIn nahm dieses Problem beispielsweise sehr ernst und hat schon 2018 an der Build-Zeit gearbeitet und von 60 Minuten auf 15 Minuten verringert. Originalzitat: “Build times improved by a factor of 150% to 400%, depending on the size of the application code. We’ve seen over 1,000 hours of productivity gains across various stages of the build lifecycle per quarter.”

Die Lösung ist also, kontinuierlich zu optimieren und zu experimentieren. Teilweise werden aber auch kurzfristige Schnellschüsse getätigt, indem einfach eine immer stärkere Hardware gekauft wird.

Hier wird aber nur auf die Produktivität Rücksicht genommen. Auf lange Sicht ist das wenig nachhaltig. Denn damit wird nur das technische Problem angegangen und vielleicht die Produktivität kurzzeitig erhöht, am Frustrationslevel der Entwickler_innen ändert sich aber nur kurzfristig etwas.

Die neue Hardware liefert am Anfang schnell schöne Ergebnisse, die Leistung verschlechtert sich aber wieder. Was dazu kommt: Die Einrichtung der Entwicklungsumgebung fällt immer wieder an, was bei großen und komplexen Projekten jedes Mal erneut Zeit frisst – auch, wenn sich das mit der Erfahrung bis zu einem gewissen Grad ändert.

Mit den richtigen Tools lässt sich aber einiges an Boden gut machen – und zwar nachhaltig. Bei incredibuild fand man heraus, dass der Einsatz der richtigen Tools zu einer Stunde an gewonnener Produktivität führte. Das sind 36 Tage im Jahr.*

Ein ganz aktuelles und konkretes Beispiel: Bei Uber ist das Problem mit dem Einsatz von Remote Development Environments gelöst worden. Wir haben das Ergebnis im Beitrag “5 Unternehmen, die RDEs bereits nutzen”, zusammengefasst. Auch Slack hat Cloud Development Environments im Einsatz, konnte die Build-Zeit verringern und sorgt damit für eine höhere Entwickler_innenzufriedenheit. O-Ton: “I’m a huge fan – this work has greatly improved my productivity and my quiet laptop fans really thank you.”

Schnelligkeit ist ein Faktor, um im Marktgeschehen zu bestehen. Langsame Build-Zeiten sind ein Blocker, der das verhindert. Mit dem Blick auf die zwei Ebenen: Produktivität und Entwickler_innenzufriedenheit können Entscheider_innen wesentlich dazu beitragen, das Unternehmen umfassend und nachhaltig zu steuern.

Fazit

Entwickler_innen verbringen viel Zeit damit, auf Dinge zu warten, bspw. auf den lokalen Build.
Das hat verschiedene Gründe: Rechenleistung, Abhängigkeiten, Änderungsumfang etc.
Das Ergebnis: Verringerte Produktivität, Frustration bei Entwickler_innen.
Die Lösung ist, kontinuierlich an einer Optimierung zu arbeiten und auch die richtigen Tools dafür einzusetzen. Dabei sollten zwei Faktoren beachtet werden: 1. Wirkt sich die Lösung nachhaltig und positiv auf die Produktivität aus? 2. Wirkt sich die Lösung nachhaltig und positiv auf die Entwickler_innenzufriedenheit aus? Eine Option sind Remote Development Environments, die diese beiden Kriterien erfüllen.

* https://www.incredibuild.com/blog/what-held-up-devs-in-2021-long-build-times