Unsere Devs sind in ihren alten Gewohnheiten gefangen und wollen wahrscheinlich keine Veränderungen

Cloud-Entwicklungsumgebungen (CDEs) zielen darauf ab, die Arbeitsweise von Entwickler_innen zu revolutionieren. Arbeitslasten verlagern sich in die Cloud, Entwicklungsumgebungen und Tools werden standardisiert. Alles mit dem Ziel, die Zeit zu reduzieren, die Entwickler_innen mit Wartezeiten und Fehlerbehebungen verbringen.

Klingt nach einem No-Brainer. Es kann jedoch schwierig sein, CDEs in Entwicklungsteams zu implementieren. Der Wechsel zu einer CDE kann eine grundlegende Änderung ihrer Arbeitsweise erfordern. Und das wollen nicht alle. Tatsächlich haben wir kürzlich in einem Interview mit einem Teamleiter folgendes gehört:

“Unsere Devs sind in ihren alten Gewohnheiten gefangen und wollen wahrscheinlich keine Veränderungen.”

Die Qualität eines Tools ist letztendlich irrelevant, wenn diejenigen, die es verwenden sollen, nicht bereit sind, ihr Verhalten zu ändern.

Veränderung ist schwer

Obwohl nicht alle Organisationen so extrem von ihren Entwickler_innen abhängig sind, ist dies insbesondere bei etablierten, älteren Organisationen durchaus üblich. In solchen Fällen gibt es in der Regel eine Kohorte von Devs die

die Codebase kennen
über besondere Kenntnisse oder Fähigkeiten verfügen, die schwer zu ersetzen sind,
über große Macht in der Auswahl der Tools und der Gestaltung der Arbeitsprozesse verfügen.

Positiver ausgedrückt: Viele Unternehmen legen Wert auf Developer Experience und möchten ihren Teams Tools und Prozesse zur Verfügung stellen, die sie gerne verwenden. Es liegt also nicht so sehr daran, dass Entwickler_innen “in ihren alten Gewohnheiten gefangen sind”, sondern eine anspruchsvolle Personengruppe sind. Sie haben hohe Erwartungen an Tools und sind schwer zu überzeugen. Aber: Wenn sie ein Fan eines Tools sind, bleiben sie dabei.

Learnings

Bei Cloudomation haben wir zwei Erkenntnisse daraus gewonnen:

Reibungslose Migration: Es muss einen einfachen und schnellen Migrationspfad von aktuellen Tools und Prozessen zu Neuen geben. Im Idealfall müssen Entwickler_innen ihre Gewohnheiten so wenig wie möglich ändern. Bezogen auf CDEs bedeutet dies, dass sich die Verwendung nicht von der lokalen Entwicklungsarbeit unterscheiden sollte. Idealerweise haben Entwickler_innen die Möglichkeit, nahtlos zwischen der Verwendung der CDE und deren lokalen Toolstack zu wechseln.
Bottom-up: Die Entwicklung und der Verkauf von Entwickler_innen-Tools funktionieren nur mit einem Bottom-Up-Ansatz. Wir müssen ein Tool entwickeln, das Entwickler_innen nutzen wollen. Und wir müssen es nach ihren Bedürfnissen und Vorlieben entwickeln.

Wie wir das machen

Bei der Entwicklung von Cloudomation DevStack war es von Anfang an eine Anforderung, für eine reibungslose Migration zu sorgen. Wir wollen DevStack so einfach wie möglich in die Arbeitsprozesse der Entwickler_innen integrieren. Das heißt:

Entwickler_innen können jede IDE / jeden Editor ihrer Wahl verwenden. Um das zu unterstützen, cached DevStack den Source Code lokal in einem freigegebenen Ordner mit der CDE. Das ist einzigartig für DevStack und erlaubt eine wirklich freie Wahl der lokalen IDE.
- Randnotiz: Es ist aber kein Muss. Entwickler_innen können sich auch dafür entscheiden, den Quellcode nicht lokal zu cachen und zum Beispiel eine SSH-fähige IDE zu verwenden.
Entwickler_innen bekommen standardmäßig vollen Zugriff auf die CDE. Das heißt: Sie öffnen ein Terminal, verbinden sich per SSH zur CDE und können dann mit den dort verfügbaren Shells und Tools arbeiten, so wie sie es über ihr lokales Terminal tun würden.
Entwickler_innen können Ordner in der CDE auswählen, die dann lokal synchronisiert werden. Wenn mit anderen Files und nicht mit Code gearbeitet werden muss, beispielsweise, wenn Änderungen überprüft werden müssen, die ihre Software an Dateien vornimmt, kann das lokal passieren – ohne Dateien zu kopieren. Für Entwickler_innen bedeutet das, dass sie so arbeiten können, wie sie es gewohnt sind, wenn sie die Software lokal deployen.
Entwickler_innen können auswählen, wie sie ihre Softwar deployen. Standardmäßig wird direkt auf der CDE-VM deployed. Entwickler_innen können jederzeit konfigurieren, wie sie deployen möchten.
Devs können bereits bestehende Konfigurationen nutzen, um ihre Cloud Dev Envs anzupassen. Beispiel: Benutzerspezifische Dotfiles können deployed werden.

Allgemein ist es unser Ansatz, so wenig wie möglich vorzugeben / anzunehmen und so viel Spielraum als möglich für individuelle Anpassungen zu lassen. Mit sinnvollen Standardeinstellungen können Entwickler_innen schnell mit der Arbeit beginnen. Aber wenn gewollt, können die CDEs nach Herzenslust angepasst werden.

Der Bottom-Up-Ansatz heißt, dass wir so früh und so häufig wie möglich Input von Nutzer_innen erhalten möchten. Im Moment führen wir viele Interviews mit Ingenieurinnen und Ingenieuren sowie technischen Leiterinnen und Leitern, um mehr über ihre Anforderungen zu erfahren. Wir selbst nutzen Cloudomation DevStack täglich und lassen unsere Entiwckler_innen priorisieren, auf was sie sich konzentrieren. Wenn Sie uns Ihre Perspektive geben wollen: Probieren Sie die öffentliche Demo von DevStack und geben Sie uns Feedback! Wenn Sie mehr wollen: Nehmen Sie an unserem Pilotkundenprogramm für DevStack teil und beeinflussen Sie mir Ihrem Feedabck direkt die weitere Entwicklung von DevStack.