“Managers of programming projects aren’t always aware that certain programming issues are matters of religion. If you’re a manager and you try to require compliance with certain programming practices, you’re inviting your programmers’ ire. Here’s a list of religious issues; Programming language, Indentation style, Placing of braces, Choice of IDE, Commenting style, Efficiency vs. readability tradeoffs, Choice of methodology – for example, Scrum vs. Extreme Programming vs. evolutionary delivery, Programming utilities, Naming conventions, Use of gotos, Use of global variables, Measurements, especially productivity measures such as lines of code per day”
Steve McConnell, Code Complete
Welcher Software Entwickler kennt nicht die Geschichte vom neuen Tool, das seine Arbeit enorm voranbringen soll. Die Firma schafft für jeden Entwickler eine Lizenz an und alle werden auf das neue Tool geschult. Drehen wir die Uhr dann einige Monate weiter, dann hat sich die Gruppe der Entwickler in mehrere Fraktionen aufgespalten. Eine kleine verschworene Gruppe von Nutzern, eine großen Fraktion von Kollegen, die das Tool unter Ihresgleichen verdammen und eine etwas kleinere Fraktion von Entwicklern, die das Tool schon lange nicht mehr benutzen.
Häufig entsteht dann eine gewisse Enttäuschung, denn immerhin erscheint das Tool doch wahnsinnig hilfreich und es hat auch eine Menge Geld gekostet. Wie das Eingangszitat belegt, ist dies kein unerwartetes Phänomen. Von der Organisation vorgegebene Tools sind in der Vergangenheit gescheitert, sie scheitern in diesem Moment und sie werden auch in Zukunft scheitern.
Software Entwickler sind eine eigenartige Mischung aus Büropersonal und autistischer Diva. Auf der einen Seite schwimmen sie gerne im Strom, andererseits fällt die eigene Produktivität außerhalb der selbst erschaffenen Biosphäre ins Bodenlose.
Wer Software Entwicklern etwas vorschreiben möchte, sollte dabei immer bedenken, dass um die Einrückungstiefe von zwei oder vier Leerzeichen gestritten wird oder ob eine öffnende geschweifte Klammer auf eine eigene Zeile gehört oder nicht. Da hat es ein neues Tools, von außen vorgegeben, nicht einfacher. Hier verbünden sich im schlimmsten Fall alle Fraktionen. Diese Ablehnung ist selten sofort zu erkennen, weil die Hybris des Entwickler ihm und seinen Vorgesetzten einen Streich spielt. Alles Neue wird erst einmal konsumiert, weil es die Neugierde triggert und von der aktuellen Tristes des Programmieralltags ablenkt.
“Wir sollen das da benutzen?”
unbekannter Kollege
Das obige ungläubige Zitat eines ehemaligen Kollegen bringt dabei die Einstellung eines Entwickler sehr genau auf den Punkt. Werbung für andere Sprachen, Frameworks und Tools sind immer willkommen, aber wehe jemand geht an den eigenen Werkzeugkasten und will da ein liebgewordenes Gerät herausnehmen.
Im Allgemein gibt es auch nur zwei Gründe für die Einführung eines neuen Tools. Jemand hat etwas Neues für eine bestehende Aufgabe gefunden oder jemand hat etwas Neues für eine neue Aufgabe gefunden. Im ersten Fall kann der Kollege das neue Tools ausprobieren aber auch wenn er begeistert ist, sollte es nicht allen anderen aufgezwungen werden. Ein gutes Tool etabliert sich nach geraumer Zeit selber in der Community. Muss eine Organisation nachhelfen, dann ist mit Sicherheit etwas faul. Häufig handelt es sich gar nicht um eine bestehende Aufgabe, sondern eine notwendig erscheinende Aufgabe soll über ein neues Tool gelöst werden. Bei notwendig erscheinenden Aufgaben handelt es sich um den zweiten Fall und dabei um Themen, für die sich Entwickler überhaupt nicht interessieren. Der Zwang diese Aufgabe übernehmen zu müssen, wird mit dem Tool assoziiert und dessen weitere Nutzung fraglich. Egal wie gut das Tool ist, keiner will es verwenden.
“Individuals and interactions over processes and tools”
Manifesto for Agile Software Development
Auch in das Agile Manifest hat es das Tool geschafft, aber auf die rechte Seite. Denn die Kollegen und das Miteinander sind wichtiger als die Verwendung eines Tools.