Ich habe in den letzten Wochen viele Gespräche zum Thema Remote Development Environments (RDEs) / Cloud Development Environments (CDEs) geführt. Grund dafür: Wir planen, ein RDE Produkt zu entwickeln (Und mittlerweile gibt es das Produkt auch schon: Cloudomation DevStack). Dazu gehört, sich gründlich Feedback und Input zu holen. Was wollen Unternehmen, was wollen Entwickler_innen, was sind Must-Haves, Dealbreaker, Wow-Features und Nice-to-Haves.
Bei meinen Gesprächen ist mir ein interessanter Widerspruch aufgefallen: Die Perspektive von Manager_innen und Entwickler_innen scheint stark auseinander zu gehen, wenn es um die Akzeptanz von RDEs geht. Um die Analyse dieses Widerspruchs, der unterschiedlichen Perspektiven und die Gründe dafür – darum geht es in diesem Beitrag.
Inhalt
Der Widerspruch: Manager_innen vs. Entwickler_innen
Manager_innen scheinen zu denken, dass RDEs ihnen viele Probleme lösen könnten, sich ihre Entwickler_innen aber quer legen würden. Entwickler_innen hingegen scheinen zu denken, dass RDEs tolle Tools für sie wären, aber das Management das wohl nicht verstehen würde. Wie kommt es dazu?
Die Perspektive der Manager_innen
Die meisten Manager_innen verstehen und bestätigen auch rasch den Mehrwert von RDEs. Sie wissen, dass ihre Entwickler_innen viel Zeit unproduktiv damit verbringen, ihre lokalen Entwicklungsumgebungen aufzusetzen, Fehler zu beheben und schlicht auf Dinge zu warten – z.B. auf das Fertigwerden des lokalen Builds.
Schlage ich ihnen RDEs als Lösungsansatz vor, sehen die meisten viele attraktive Vorteile der angebotenen Features in den RDEs. Wie z. B. die Absicherung von Source Code und Testdaten, die Standardisierung der Umgebungen und die zentrale Verwaltung über ein System. Sorge gibt es aber in Bezug auf Akzeptanz bei Entwickler_innen.
Warum?
Manager_innen scheinen grundsätzlich davon auszugehen, dass RDEs etwas sind, was Entwickler_innen nicht wollen. Auch wenn sie mir sagen, dass es für sie ein interessantes Produkt wäre, scheinen sie fix anzunehmen, dass sie die Einführung von RDEs gegen den Widerstand von Entwickler_innen würden durchsetzen müssen.
Die Perspektive der Entwickler_innen
Spreche ich mit Entwickler_innen, ist das Feedback meist unmittelbar positiv. Sofort wird bestätigt, dass lokale Entwicklungsumgebungen mühsam sind. Auch Entwickler_innen, die sich gerne mal mit DevOps Themen beschäftigen, gestehen ein, dass es schöner wäre, wenn sie Probleme mit ihrem lokalen Build o.ä. nachhaltiger lösen könnten. Eben nachhaltiger als der übliche quick-fix am eigenen Laptop, den man eigentlich nur so schnell wie möglich irgendwie hin hackt, damit man wieder weiterarbeiten kann.
Viele Entwickler_innen sprudeln geradezu vor Ideen für Features, die sie sich in RDEs wünschen und die ihnen das Leben leichter machen würden. Allem Voran steht, sich nicht mehr darum kümmern zu müssen, dass alles funktioniert: Per Knopfdruck eine vorkonfigurierte Entwicklungsumgebung in der die zu entwickelnde Software einfach läuft, in der der Build schnell geht, in der alle Tools, die sie brauchen flüssig laufen.
Das deckt sich mit meiner Perspektive. Ich sehe RDEs primär als ein Tool für Entwickler_innen. Etwas, das ihnen Zeit sparen und das Leben leichter machen soll. Unser RDE-Tool soll auch primär an den Anforderungen von Entwickler_innen ausgerichtet sein. Aus meiner Sicht muss eine RDE etwas sein, das Entwickler_innen haben wollen und gerne benutzen.
Frage ich Entwickler_innen, ob sie denken, für so etwas gäbe es in ihrem Unternehmen Budget, meinen die meisten, sie wüssten es nicht: Developer Experience wäre nicht oberste Priorität. Sie gehen tendenziell davon aus, dass sie nicht gehört werden, wenn sie im Management nach RDEs fragen würden.
Die Produktivität Ihres IT-Teams mit Remote Development Environments auf das nächste Level heben
In diesem Whitepaper erfahren Sie, wie Remote Development Environments (RDEs) helfen, den Aufwand für die Wartung der lokalen Entwicklungsumgebung zu reduzieren und die Produktivität Ihres IT-Teams zu erhöhen.
Jetzt herunterladenWie kommt es zu diesen unterschiedlichen Perspektiven?
“Warum würden Entwickler_innen das nicht mögen?”
Wenn ich das frage, antworten die meisten Manager_innen, dass Entwickler_innen volle Kontrolle und freien Entscheidungsspielraum über ihre Entwicklungsumgebungen haben wollen. Wenn man ihnen standardisierte Umgebungen hinklatscht, die sie verwenden müssen und die sie nicht bis ins letzte customisen können, dann würden sie das wohl nicht haben wollen.
Dagegen steht das Wort vieler Entwickler_innen. Sie sagen wiederum, sie wünschen sich ein Ding, das sie auf Knopfdruck deployen können und das einfach funktioniert. Um das sie sich nicht kümmern müssen. Keine einzige Entwicklerin hat mir rückgemeldet, dass unendliche Anpassbarkeit eine Anforderung wäre. Sehr wohl sei aber wichtig, dass die RDE nicht im Weg sei. Also alles, was eine Entwicklerin braucht, um produktiv zu arbeiten, muss möglich sein.
Den Root-Zugriff verlangen Entwickler_innen aber keineswegs aus Prinzip oder Machtgeilheit, sondern leider rein aus Notwendigkeit. Den meisten wäre es viel lieber, wenn sie ihn nicht bräuchten. Damit sie sich nicht damit auseinandersetzen müssen, welche Packages in welcher Version mit welchen Zugriffsrechten vorhanden sind, um das bei Bedarf geradebiegen zu können. Die meisten wollen sich damit nicht befassen. Die meisten Software Entwickler entwickeln am liebsten Software und überlassen das Operating den Kolleg_innen im Operating.
Überschätzen Manager_innen den Kontrollwunsch von Entwickler_innen? Unterschätzen sie den Pragmatismus (man könnte ihn auch als Faulheit bezeichnen) von Entwickler_innen? Woher kommt diese Perspektive von der Entwicklerin, die sich gerne stundenlang damit auseinandersetzt, wie sie das Farbschema ihrer IDE customisen kann, die aber auf die Barrikaden steigt, wenn man ihr diese Möglichkeit nimmt? Und woher kommt die Annahme, dass standardisierte Tools, die vom Management vorgegeben werden, grundsätzlich nicht dem entsprechen, was Entwickler_innen haben wollen?
Ich kenne Entwickler_innen als pragmatisches Volk. Customising der eigenen Entwicklungsumgebung geschieht primär im Dienste der Produktivität: Sie richten sich die eigene Umgebung so ein, dass sie so schnell wie möglich ans Ziel kommen. Ich kenne Entwickler_innen als tendenziell faule Leute (Im Dienste der Produktivität!), die auch kleine Dinge automatisieren, damit sie sie nie wieder machen müssen. Dabei unterschätzen sie manchmal den Aufwand der Automatisierung, sodass der ROI für manche Dinge negativ sein mag. Aber das Arbeiten an Developer-Tools geschieht meiner Erfahrung nach nur in den seltensten Fällen aus Spaß am Basteln und meistens aus dem Wunsch, Zeit zu sparen und Produktivität zu erhöhen.
Ich selbst bin Managerin und kenne das Stirnrunzeln gut, das auch mir manchmal kommt, wenn sich unsere Entwickler_innen aus meiner Sicht zu viel mit Ihrem Tooling beschäftigen. Immer wieder braucht es von mir die Frage, wie groß das Problem denn wirklich und wie teuer die Lösung sei. Auf diese Frage antworten Entwickler_innen auch meistens pragmatisch: “Ja, gut, lohnt sich nicht.”
Diese Antwort kommt oft mit Erleichterung. Weil: Die wenigsten Entwickler_innen machen das gerne; Dinge wie das lokale Build-Skript erweitern oder die CI/CD Pipeline troubleshooten oder sich schon wieder damit auseinandersetzen, warum seit dem letzten Docker Update lokal einfach gar nichts mehr funktioniert. Wenn ich entscheide, dass sie das Problem jetzt so schnell wie möglich lösen und nicht viel Zeit in eine generische Lösung investieren sollen, dann ist die Reaktion meist eine Mischung aus Erleichterung, sich jetzt nicht lange damit befassen zu müssen und Furcht davor, dass das Problem wieder kommt und sie das gleiche nochmal machen müssen.
Die Interessen sind also die gleichen: Manager_innen und Entwickler_innen wollen beide so wenig Zeit wie möglich mit unproduktivem Troubleshooting verbringen und so viel Zeit wie möglich Code schreiben.
Warum sind die Perspektiven dann dennoch so unterschiedlich? Warum klaffen die Meinungen darüber, wie man dieses gemeinsame Ziel erreichen kann, so auseinander?
Der Grund für die unterschiedlichen Perspektiven
Ein Grund für die unterschiedlichen Perspektiven ist sicherlich, dass Manager_innen und Entwickler_innen einfach unterschiedliche Anforderungen an RDEs haben, bzw. sie aus unterschiedlichen Gründen attraktiv finden.
Da Manager_innen meist die Personen mit dem Budget sind, kann es gut sein, dass Produkte häufig stärker nach deren Bedürfnissen ausgerichtet sind als nach den Bedürfnissen der Anwender_innen – in dem Fall Entwickler_innen.
| Manager_innen | Entwickler_innen |
|---|---|
|
|
Dabei gibt es unterschiedliche Ziele, die verfolgt werden: Manager_innen sind stärker in der Verantwortung für Risiko und Sicherheit, und daher eher an Funktionalitäten interessiert, die die Sicherheit erhöhen und das Risiko minimieren.
Entwickler_innen erleben Sicherheitsfeatures häufig als “im Weg stehende Last”. Das ist ein klassischer Konflikt. Hier sehe ich es als Aufgabe der Tool-Hersteller, eine Balance zu ermöglichen, die ausreichende Sicherheit zu ausreichenden Kosten (in Entwicklerzeit) ermöglicht.
In den großen Bereichen decken sich die Interessen von Manager_innen und Entwickler_innen aber: Beide wollen die Zeit der Entwickler_innen möglichst effizient nutzen. Sie sehen unterschiedliche Features als zweckdienlich für dieses Ziel – weswegen die grundsätzliche Bereitschaft, sich mit Entwickler-Tooling auseinanderzusetzen bei Entwickler_innen höher ist als bei Manager_innen. Aber dennoch: die Ziele stimmen überein.
Deswegen sind sowohl Manager_innen als auch Entwickler_innen überzeugt davon, dass RDEs eine sinnvolle Sache sind. Dennoch denken beide, die jeweils andere Gruppe würde das nicht so sehen. Woran liegt das?
Des Pudels Kern
Der Kern der Sache ist ganz einfach: es geht um Macht. Es geht darum, wer die Entscheidung trifft.
Wenn ich mich auf Augenhöhe mit Entwickler_innen zusammensetze und sie frage, was sie sich von einem RDE Tool wünschen würden, dann gehen sie davon aus,
- dass es etwas ist, das für sie gemacht ist,
- an ihnen ausgerichtet ist,
- ihnen nützlich sein soll,
- dass sie diejenigen wären, die sich dieses Tool aussuchen und entscheiden, es zu verwenden.
Ist das der Fall, ist die Akzeptanz natürlich hoch.
Wenn ich mit Manager_innen spreche, die in der Vergangenheit vielleicht schon Tools eingeführt haben, die sie nach ihren Kriterien ausgewählt haben, haben sie bereits konkret die Erfahrung gemacht, dass Entwickler_innen Widerstand leisten. Schon alleine, weil sie etwas “aufs Auge gedrückt bekommen”, was sie sich nicht ausgesucht haben.
Fazit: Der Entscheidungsprozess für die Wahl eines RDE Tools muss ganz unbedingt von beiden Seiten mitgetragen werden. Das Produkt an sich muss für beide Seiten wertvolle Features mitbringen. Vor allem aber muss es an dem einen, gemeinsamen Ziel ausgerichtet sein: es muss Entwickler_innen Zeit sparen, denn darum geht es sowohl den Entwickler_innen selbst als auch dem Management.
Jetzt den Cloudomation-Newsletter abonnieren
Werden Sie Cloudomation-Insider. Immer am Ende des Monats neue News zum Thema „Remote Development Environments“ und „DevOps“ erhalten.
