Developer sind verantwortungslose Spielkinder!

Inhaltsverzeichnis

Wenn man auf Entwickler*innen nicht aufpasst, machen sie den ganzen Tag Unsinn. Wie soll man damit umgehen?

Relativ häufig wird mir die Frage gestellt: "Wie kontrolliert man die Technologieauswahl im Team?" In der Diskussion zeigt sich dann die Meinung, dass Entwickler*innen Technologieentscheidungen eigentlich nicht treffen sollten. Das Projekt würde sonst in Chaos und Anarchie versinken, weil alle denkbaren Technologien genutzt werden. Developer sind schließlich verantwortungslose Spielkinder! Die Leidtragenden, wenn Projekte in Chaos und Anarchie versinken, sind aber Entwickler*innen. Es ist also in ihrem besten Interesse, Technologien mit Augenmaß zu nutzen. Das spielt in der Diskussion aber nur selten eine Rolle.

Die nächste Eskalationsstufe sind Äußerungen wie "Meine 14-jährige Tochter programmiert auch und die bekommt das schneller hin als diese Entwickler" oder "Mit den Entwicklerinnen hier kann man moderne Ideen eh nicht umsetzen". Entwickler*innen sind hochqualifizierte Expert*innen. Software gehört zum Komplexesten, was Menschen überhaupt produzieren können. Ich halte solche Äußerungen schlicht für respektlos.

Kontrolle

Aber nehmen wir an, dass Developer tatsächlich verantwortungslose Spielkinder sind. Dann kann man anscheinend nur auf Kontrolle setzen. Das führt zu klaren Richtlinien, beispielsweise bezüglich zu nutzender Technologien oder Coding-Standards, idealerweise mit automatisierter Überprüfung.

Sicherlich können solche Maßnahmen sinnvoll sein. Aber die Kontrollen funktionieren oft nur schlecht: In einem meiner ersten Großprojekte haben wir gemeinsam einige Coding-Richtlinien festgelegt und mit Werkzeugen automatisiert überprüft. Nach einiger Zeit gab es keine Verstöße, aber nur scheinbar: In Wirklichkeit hatten einige Entwickler*innen die Werkzeuge an bestimmten Code-Stelle einfach deaktiviert. So kann ein sinnloser Wettlauf mit zunehmend mehr Kontrolle und dem Unterwandern der Kontrollen beginnen.

Offensichtlich kommt man so also nicht weiter. Und Kontrolle skaliert auch nicht: Man kann nicht als einzelne Person alles verstehen, kontrollieren und korrigieren, was ein ganzes Team produziert. Wer den Anspruch an sich hat, der muss scheitern. Passend dazu zeigt die in diesem Blog schon einmal zitierte empirische Untersuchung in der “State of DevOps”-Studie, dass ein schwergewichtiger Änderungsprozess die Leistungsfähigkeit der Softwareentwicklungsorganisation negativ beeinflusst. Mehr Kontrolle und Overhead sind also wohl kaum die Lösung.

Lösungen

Von Fred George habe ich sinngemäß einen Satz im Ohr: "Developer wollen an Dingen tüfteln. Also gib ihnen Dinge zum Tüfteln!" Daraus leitet er in seinem Modell weitgehende Freiheiten für Entwickler*innen ab. Außerdem tüfteln sie dann nicht nur am Code, sondern direkt an Geschäftszielen wie Umsatzsteigerung oder Kundenzufriedenheit. Bezeichnenderweise heißt das Modell "Developer Anarchy". Wie kann das funktionieren? Schließlich sind Developer doch verantwortungslose Spielkinder!

Vielleicht sind sie doch verantwortungsvolle Personen? Immerhin kenne ich durchaus einige Entwickler*innen, die im privaten Leben erhebliche Budgets auf eigenes Risiko verwalten – beispielsweise beim Hausbau. Ihre Fähigkeiten sind ihnen auch wichtig. Sie programmieren auch in ihrer Freizeit oder nehmen zum Beispiel an abendlichen Meetups oder an Coderetreats an Wochenenden teil. Das zeugt von einer hohen Motivation, die eigenen Fähigkeiten sogar in der Freizeit ständig weiterzuentwickeln.

Respekt

Meiner Meinung nach ist der einzige Weg aus dieser Situation, zunächst einmal Respekt vor Entwickler*innen und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialist*innen für Code wahr – was sie auch sind.

Vertrauen und Delegation können das Verhalten ändern und eine Voraussetzung für verantwortungsvolles Handeln sein. Wenn Entwickler*innen in ihren Augen sinnlose Entscheidungen umsetzen müssen, werden sie versuchen, diese Entscheidungen zu unterlaufen. Wenn das gesamte Projekt sinnlos erscheint, werden sie sich Ecken suchen, in denen sie herumspielen können. Wenn Entwickler*innen aber selbst Entscheidungen treffen, werden sie sich anders verhalten müssen. Sie können nicht einfach nur kritisieren, sondern müssen selbst konstruktiv sein. Außerdem müssen sie mit den Konsequenzen leben – also werden sie sich die Entscheidungen gut überlegen.

Als Bezeichnung für einen Schritt hin zu mehr Vertrauen finde ich "Leap of Faith" (Sprung des Glaubens) gut: Man glaubt an die Entwickler*innen und springt ins Unbekannte, was natürlich Mut erfordert.
Wenn ihr Vorgehen optimierbar ist, hilft Kontrolle eben nicht weiter, denn diese lässt sich halt unterlaufen. Stattdessen sollten Wissensaustausch und -transfer im Fokus stehen. Wenn Entwickler*innen sowohl die Ziele als auch ihre technische Umsetzung verstanden haben, gibt es eine relativ hohe Wahrscheinlichkeit, dass sie die Konzepte der technischen Umsetzung auch befolgen. Und wenn nicht: War es vielleicht doch keine gute Idee? Vielleicht haben sie sogar eine bessere? So kann es offene, produktive Diskussionen und Verbesserungen geben.

So tritt an die Stelle von Kontrolle eine Zusammenarbeit, bei der unterschiedliche Sichtweisen der Beteiligten ausgetauscht werden und so sogar noch bessere Lösungen entstehen, als dies durch Kontrollen alleine möglich wäre. Entwickler*innen sind eben auch Spezialist*innen für ihren Bereich.

Management

Nun kann man natürlich sagen, dass Management und Architekt*innen endlich den Entwickler*innen gegenüber den nötigen Respekt und das nötige Vertrauen zollen müssen – und damit ist das Problem endlich gelöst!

Respekt ist aber keine Einbahnstraße. Entwickler*innen müssen auch Management und Architekt*innen Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Expert*innen – nur eben in anderen Bereichen. Architekt*innen können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

tl;dr

Wechselseitiger Respekt und Vertrauen sind die Grundlage für erfolgreiche Zusammenarbeit.

Vielen Dank an meine Kolleginnen und Kollegen Christoph Iserlohn, Robert Glaser, Anja Kammer, Michel Krämer, Martin Kühl, Stefan Tilkov, Hermann Schmidt und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels. ()