Featured

de.buildblog.reflect – Die Kunst der egoreduzierten Softwareentwicklung

Wer kennt sie nicht, die beste Umschreibung eines Teams. “Toll ein Anderer machts”. Schon in der Schule lernen wir das Teamworking, oder besser gesagt: die Abschiebung der zu erledigenden Arbeit auf die Anderen.

Nun gelinde gesagt, ist das was man üblicherweise als Teamwork, Gruppenarbeit, etc. präsentiert bekommt, das Hinterletze. Es rückt die Leistung des Einzelnen derart in den Hintergrund dass er sich in der gesichtslosen Masse auflöst. Das führt zu mehreren Problemen. Zu einen schwindet die Motivation guter Leute dadurch, dass sie

• die Anderen “durchschleppen” müssen
• die Gesamtleistung der Gruppe eingeschränkt wird
• ihre eigene “Genialität” in den hintergrund gedrängt wird

Zum Anderen führen Gruppen meist zu einem schnell ausufernden Kommunikationsaufwand bei der bewältigung der Alltagprobleme. Dafür gibt es ein paar interessante “Abwehrmeschanismen”, aber der Reihe nach.

Willkommen im dritten Teil meiner Serie für allgemeine Softwareentwicklung.

Egoreduzierte Softwareentwicklung und die kognitive Dissonanz des Entwicklers

Die folgenden Zeilen sind die Grundvoraussetzung um das, was ich hier sagen, will nicht misszuverstehen. Ich behaupte Menschen und ihre differenzen sind das Hauptproblem in jedem Team unabhängig von seiner Organisation. Wir reden also wie üblich von “Befindlichkeiten”, im vorliegenden Falle über befindlichkeiten von Softwareentwicklern. In den nicht ganz sauber ausgearbeiteten Stereotypen kommt man zumindest zu einer Erkenntniss. Diese ist, wie ich finde, recht trivialer Natur, aber für diejenigen, die das “Programmierergesocks” für einen humoristischen Beitrag hielten, sage ich es nochmal in aller deutlichkeit: Menschen sind unterschiedlich. Sie leben unterschiedlich, haben unterschiedliche Wissenstände und organisieren sich unterschiedlich. Diese umstände haben selbstverständlich zur Folge, dass sie auch unterschiedlich arbeiten.

Es gibt zwei Eigenschaften die einem Softwareentwickler innewohnen sollten, wobei die letzere (leider) recht selten vorhanden ist:

• die Fähigkeit des analytisch, logischen Denkens und
• die Fähigkeit genau das gegenteil zu tun, “um die Ecke” zu denken und dadurch unkonventionelle Wege zu gehen. Zugegebenermaßen ist das eine Eigenschaft die nicht jedem Softwareentwickler innewohnen kann allerdings ist das überwinden des denkbaren auch im normalen Leben manchmal recht hilfreich.

Soziale kompetenz gilt zwar nicht unbedingt als allgemein anerkannte Stärke allerdings ist sie zumindest innerhalb eines Entwicklungsteams unbedingte Vorraussetzung für das Gelingen von Projekten. Programmierer müssen zumindest mit ihres gleichen auskommen. In der Regel klappt das auch ganz gut.

Aber zurück zum Kern.

Die Fähigkeit des analytischen Denkens hat ein paar massive Auswirkungen auf Persönlichkeiten, denen diese Eigenschaft innewohnt. Stellen wir uns vor ein Programmierer entwicklelt eine zentrale Applikation die eine Menge Fehler im Systemumfeld verursacht. Das Programm funktioniert also nicht. Es ist Fehlerhaft oder weitergedacht: Nutzlos und sogar Schädlich. Um es mit Weinberg´s Worten zu sagen. Der Entwickler dieses Programms hat jetzt ein massives Problem. Der Code ist sein Werk. Er ist ein Teil davon. Da der Entwickler diesen hervorgebracht hat, ist ist Bestandteil und Verursacher des Problems und als Bestandteil, bleibt ihm selbst nicht viel übrig als sich für fehlerhaft und wertlos zu halten. Um das mal auf die spitze zu treiben: Wir hätten vermutlich eine erheblich höhere Suizidquote als dies augenblicklich der Fall ist, wenn die Konsequenzen aus Gedankengeängen derart radikal wären.

(Un-)Glücklicherweise gibt es da in der Sozialpsychologie die Theroie der kognitiven Dissonanz die dem Programmierer jetzt sagt: Du hast alles richtig gemacht, schiebe die Schuld auf die Anderen oder auf höhere Gewalt und Unvorhersehbarkeiten. In Entwicklerjargon ausgedrückt: Der Compiler hat die Schuld, die IDE hat die Schuld oder der Kollege hat die Schnittstelle versemmelt. Damit ist man dann aus der Sache, wie man so schön sagt, ”fein raus”. Allerdings ist anzuzweifeln ob es so fein ist, denn das Problem besteht weiterhin. Es sollte also unser Ziel sein dieses zu vermeiden. Der Hemmschuh liegt hier offenkundig im Ego des Entwicklers. Aus verschiedensten Gründen ist er nicht gewillt oder in der Lage das Problem einzugestehen oder von vorn herein zu vermeiden.

Ich habe weiter oben bereits erwähnt, dass es ein Fehler ist Leute durchzuschleppen und dadurch die Leistung des Einzelnen in den hinterrgund zu rücken. Was aber, wenn es keinen Einzelkämpfer mehr gibt?

Hier gehts zur Fortsetzung…

© 2009 buildblog.