Wikipedia:WikiProjekt Frauen/Geschlechtergerechte Sprache/Workshop zu Gender-Schreibweisen

 GS-Materialien 

 Studien,Literatur,Video 

 Workshop 

 Nichtbinär-Workshop 

WikiProjekt Frauen

WP: Gender-Gap

Diskussion

Workshop zu Gender-Schreibweisen

Es folgt ein veröffentlichter Artikel, hier aufbereitet mit 16 unterschiedlichen Gender-Schreibweisen (zum Ausklappen). Eine davon hat der Autor, ein moderner Architekt, verwendet.

Welche Form des Genderns liest sich flüssig, welche gefällt?

Zur Aussprache von gegenderten Kurzformen mit Glottisschlag siehe „Gender-Pause“.

Projektbetreuung:  Chiananda (Diskussion), empfiehlt den Apostroph
19. Juni 2022, 02:48 Uhr

Maskulinum

generische Maskulinform: Entwickler

Developer sind verantwortungslose Spielkinder! Wenn man auf Entwickler 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 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. 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 sind hochqualifizierte Experten. 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 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 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, 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 und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialisten 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 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 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 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 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 sind eben auch Spezialisten für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und Architekten endlich den Entwicklern 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 müssen auch Management und Architekten Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Experten – nur eben in anderen Bereichen. Architekten können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

Femininum

generische Femininform: Entwicklerinnen

Developer sind verantwortungslose Spielkinder! Wenn man auf Entwicklerinnen 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 Entwicklerinnen 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 Entwicklerinnen. 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“. Entwicklerinnen sind hochqualifizierte Expertinnen. 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 Entwicklerinnen 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 Entwicklerinnen 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 Entwicklerinnen, 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 Entwicklerinnen und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialistinnen 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 Entwicklerinnen 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 Entwicklerinnen 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 Entwicklerinnen 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 Entwicklerinnen 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. Entwicklerinnen sind eben auch Spezialistinnen für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und Architektinnen endlich den Entwicklerinnen 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. Entwicklerinnen müssen auch Management und Architektinnen Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Expertinnen – nur eben in anderen Bereichen. Architektinnen können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

Beidnennung

Beidnennung: Entwicklerinnen und Entwickler

Developer sind verantwortungslose Spielkinder! Wenn man auf Entwicklerinnen und Entwickler 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 Entwicklerinnen und Entwickler 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 Entwicklerinnen und Entwickler. 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“. Entwicklerinnen und Entwickler sind hochqualifizierte Expertinnen und Experten. 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 Entwicklerinnen und Entwickler 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 Entwicklerinnen und Entwickler 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 Entwicklerinnen und Entwickler, 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 Entwicklerinnen und Entwickler und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialistinnen und Spezialisten 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 Entwicklerinnen und Entwickler 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 Entwicklerinnen und Entwickler 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 Entwicklerinnen und Entwickler 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 Entwicklerinnen und Entwickler 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. Entwicklerinnen und Entwickler sind eben auch Spezialistinnen und Spezialisten für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und Architektinnen und Architekten endlich den Entwicklerinnen und Entwickler 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. Entwicklerinnen und Entwickler müssen auch Management und Architektinnen und Architekten Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Expertinnen und Experten – nur eben in anderen Bereichen. Architektinnen und Architekten können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

Schrägstrich, vollständig

Paarform mit Schrägstrich: Entwickler/Entwicklerinnen

Developer sind verantwortungslose Spielkinder! Wenn man auf Entwickler/Entwicklerinnen 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/Entwicklerinnen 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/Entwicklerinnen. 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/Entwicklerinnen sind hochqualifizierte Experten/Expertinnen. 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/Entwicklerinnen 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/Entwicklerinnen 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/Entwicklerinnen, 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/Entwicklerinnen und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialisten/Spezialistinnen 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/Entwicklerinnen 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/Entwicklerinnen 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/Entwicklerinnen 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/Entwicklerinnen 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/Entwicklerinnen sind eben auch Spezialisten/Spezialistinnen für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und Architekten/Architektinnen endlich den Entwickler/Entwicklerinnen 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/Entwicklerinnen müssen auch Management und Architekten/Architektinnen Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Experten/Expertinnen – nur eben in anderen Bereichen. Architekten/Architektinnen können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

Schrägstrich, abgekürzt

Schrägstrich mit Auslassungsstrich: Entwickler/-innen

Developer sind verantwortungslose Spielkinder! 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.

Schrägstrich, einfach

einfacher Schrägstrich: Entwickler/innen

Developer sind verantwortungslose Spielkinder! 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.

Apostroph

Apostroph: Entwickler’innen

Developer sind verantwortungslose Spielkinder! 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.

Klammern

Klammern: Entwickler(innen)

Developer sind verantwortungslose Spielkinder! 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(inn)en. 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(inn)en 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(inn)en für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und Architekt(inn)en 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(inn)en Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Expert(inn)en – nur eben in anderen Bereichen. Architekt(inn)en können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

Binnen-I

Binnen-I: EntwicklerInnen

Developer sind verantwortungslose Spielkinder! Wenn man auf EntwicklerInnen 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 EntwicklerInnen 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 EntwicklerInnen. 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“. EntwicklerInnen sind hochqualifizierte ExpertInnen. 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 EntwicklerInnen 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 EntwicklerInnen 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 EntwicklerInnen, 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 EntwicklerInnen und ihren Qualifikationen aufzubauen. Ich nehme sie als SpezialistInnen 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 EntwicklerInnen 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 EntwicklerInnen 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 EntwicklerInnen 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 EntwicklerInnen 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. EntwicklerInnen sind eben auch SpezialistInnen für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und ArchitektInnen endlich den EntwicklerInnen 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. EntwicklerInnen müssen auch Management und ArchitektInnen Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls ExpertInnen – nur eben in anderen Bereichen. ArchitektInnen können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

m/w/d

Klammerzusatz: Entwickler (m/w/d)

Developer sind verantwortungslose Spielkinder! Wenn man auf Entwickler (m/w/d) 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 (m/w/d) 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 (m/w/d). 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 (m/w/d) sind hochqualifizierte Experten (m/w/d). 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 (m/w/d) 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 (m/w/d) 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 (m/w/d), 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 Entwicklern (m/w/d) und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialisten (m/w/d) 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 (m/w/d) 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 (m/w/d) 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 (m/w/d) 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 (m/w/d) 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 (m/w/d) sind eben auch Spezialisten (m/w/d) für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und Architekten (m/w/d) endlich den Entwicklern (m/w/d) 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 (m/w/d) müssen auch Management und Architekten (m/w/d) Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Experten (m/w/d) – nur eben in anderen Bereichen. Architekten (m/w/d) können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

Sternchen

Gendersternchen: Entwickler*innen

Developer sind verantwortungslose Spielkinder! 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. = Originaltext 23.06.2020: durchgehend genderneutral formuliert

Doppelpunkt

Gender-Doppelpunkt: Entwickler:innen

Developer sind verantwortungslose Spielkinder! 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.

Unterstrich

Gender-Gap: Entwickler_innen

Developer sind verantwortungslose Spielkinder! 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.

Mediopunkt

Mediopunkt: Entwickler·innen

Developer sind verantwortungslose Spielkinder! 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.

X-Endung

X-Endung: Entwicklex

Developer sind verantwortungslose Spielkinder! Wenn man auf Entwicklexs 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 Entwicklexs 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 Entwicklexs. 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“. Entwicklexs sind hochqualifizierte Expertexs. 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 Entwicklexs 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 Entwicklexs 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 Entwicklexs, 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 Entwicklexs und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialistexs 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 Entwicklexs 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 Entwicklexs 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 Entwicklexs 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 Entwicklexs 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. Entwicklexs sind eben auch Spezialistexs für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und Architektexs endlich den Entwicklexs 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. Entwicklexs müssen auch Management und Architektexs Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Expertexs – nur eben in anderen Bereichen. Architektexs können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

Y-Endung

Y-Endung: Entwicklys

Developer sind verantwortungslose Spielkinder! Wenn man auf Entwicklys 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 Entwicklys 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 Entwicklys. 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“. Entwicklys sind hochqualifizierte Expertys. 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 Entwicklys 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 Entwicklys 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 Entwicklys, 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 Entwicklys und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialistys 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 Entwicklys 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 Entwicklys 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 Entwicklys 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 Entwicklys 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. Entwicklys sind eben auch Spezialistys für ihren Bereich. Management Nun kann man natürlich sagen, dass Management und Architektys endlich den Entwicklys 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. Entwicklys müssen auch Management und Architektys Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Expertys – nur eben in anderen Bereichen. Architektys können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.

Der Autor des Textes

Der Autor des vollumfänglich zitierten Artikels Developer sind verantwortungslose Spielkinder! In: Heise online 23. Juni 2020:

• Eberhard Wolff arbeitet als Fellow bei INNOQ. Er ist seit mehr als 15 Jahren als Architekt und Berater tätig – oft an der Schnittstelle zwischen Business und Technologie. Sein technologischer Schwerpunkt liegt auf modernen Architektur-Ansätzen – Cloud, Continuous Delivery, DevOps, Microservices oder NoSQL spielen oft eine Rolle. Er ist Autor von über hundert Artikeln und Büchern. Sein letztes Buch hatte Continuous Delivery als Thema. Außerdem spricht er regelmäßig auf verschiedenen Konferenzen und gestaltet einige Konferenzen auch als Mitglied im Programmkomitee.^[1]

Zum Artikel gab es 426 Kommentare von angemeldeten Forumsmitgliedern, fast alle zu der gewählten Gender-Schreibweise, und größtenteils ablehnend – vermutlich die gleiche Anzahl musste wegen beleidigenden Inhalts gelöscht werden. Außerdem wurde ein eigener Diskussionsstrang abgekoppelt, um der Empörung Herr zu werden: Gendering bei Heise Online – auch dort mussten viele ausfällig werdende Kommentare entfernt werden.

Siehe auch

• Gender-Pause (Aussprache von verkürzten Paarformen mit Glottisschlag)
• Liste deutschsprachiger Einrichtungen, die Genderzeichen nutzen (rund 200)
• Gendersternchen: Debatten Pro und Kontra (Weblinks)
• Rezeption von geschlechtergerechter Sprache (Akzeptanz und Kritik)
• Geschlechtergerechte Sprache: Debatten Pro und Kontra (Weblinks)
• Studien und Umfragen zu geschlechtergerechter Sprache, Genderzeichen und Glottisschlag
• Workshop „Geschlechtsneutrale Biografie“ (Chiananda)

Portal Frauen: Gendergerechte Sprache – Leitfäden, Presse, Studien, Videos