Retroperspektivischer Negationseffekt

Der retroperspektivische Negationseffekt ist ein psychologischer Schutzmechanismus, der sich mit zunehmendem Alter verstärkt.

Grundbetrachtung

Programmierer sind nicht von Natur aus sarkastisch, vielmehr ist es eine natürliche Schutzreaktion des gesunden Geistes, die einen davor bewahrt den Verstand zu verlieren. Sie bewahrt uns auch davor hemmungslos auf jemanden einzuschlagen, unkontrolliert herum zu schreien oder in endlosen Sturzbächen aus Tränen der Verzweiflung zu ertrinken. So viele Tränen können gar nicht vergossen werden, wie manchmal von Nöten wären, um den Schmerz zu überwinden, der einem durch die Glieder fährt, wenn bestimmte Dinge passieren. Sehr bestimmte Dinge. Schmerzvolle Dinge. Und wenn diese Dinge geschehen, ist es also nur natürlich, sarkastisch zu werden. Und aus diesem Sarkasmus heraus entwickelten wir eines schmerzvollen Tages dann den retroperspektivischen Negationseffekt. Anlass dazu war ein altbekanntes Phänomen der Softwareentwicklung, dass aber auch in alle anderen Lebensbereiche reflektiert werden kann.

Fall 1

Wenn man beispielsweise vor einem Jahr vom Rad gestürzt ist und sich damals tierisch wehgetan hat, die Rippen geprellt und den Arm gebrochen hat, ist das im Moment des Geschehens wirklich schlimm. Die Schmerzen, diese endlosen, quälenden Schmerzen, dann die Operation, der Gips, die Zeit der Regeneration – der pure Horror.
Ein Jahr später verschwimmen auf einmal die Erinnerungen, man erinnert sich nur noch an den Unfall und den Gips, aber die Schmerzen geraten irgendwie in Vergessenheit und je mehr Gespensterpisse auf die Gräber unserer Feinde herab rieselt, je mehr verschwimmt alles zu einer dumpfen Erinnerung, die aber – retroperspektivisch betrachtet – nicht mehr ansatzweise so schlimm war wie zum Zeitpunkt des Geschehens.

Man kann also sagen:

„Je länger es her ist, desto weniger schlimm wirkt es jetzt.“

Fall 2

Ein anderes Beispiel, das Essen in der Kantine vorletzte Woche.
Diese total ekelhafte, verbrannte, knochentrockene, nach nichts schmeckende Pizza Salami. Ekelhaft. Wie kann man so blöd sein und eine Pizza derart versauen? Nachdem man diese Pizza soweit es geht in sich hinein gestopft hat und einem so richtig schön schlecht wurde, hat man sich gesagt „Boah, ööööh mein Bauch, nie wieder esse ich eine Pizza in unserer Kantine. Bähh“.

Die Zeit vergeht und es kommen einige Gerichte dazwischen, die gar nicht mal so schlecht schmecken, vielleicht gibt es sogar eins, dass gut geschmeckt hat! Zwei Wochen später gibt es in der Kantine wieder Pizza. Die Erinnerung an dieses schreckliche Ereignis sollte uns eigentlich eines besseren belehren, aber da inzwischen zwei Wochen vergangen sind, ist das alles nicht mehr so wild. Okay, die Pizza war nicht toll, aber Hey, dass kann ja mal passieren. Die Pizza sieht doch eigentlich nur am Rand ein wenig verkokelt aus. Und was macht man? Man isst wieder diese Pizza und sie ist nicht nur am Rand verkokelt. Und man kann sie vielleicht als Frisbee verwenden, aber zum Essen ist sie bestimmt nicht geeignet. Wieder reingefallen.

Schlußfolgender Vergleich

Und dieses Prinzip findet in ähnlicher Form – aber mit dem gleichen erschreckenden Resultat - auch in der Softwareentwicklung statt.

„Je länger es her ist, desto weniger schlimm wirkt es jetzt.“

Das Ding ist nur, dass dies auf Consultants weitaus mehr zutrifft, als auf Softwareentwickler. Für Softwareentwickler gilt in den meisten Fällen sogar das genaue Gegenteil:

„Je länger es her ist, desto schlimmer wird es wieder werden.“

Themenbezogene Betrachtung

Ein epochales und erdrückendes Beispiel hierfür – das sich täglich tausendfach in allen möglichen Firmen dieser Welt wiederholt:

Ablauf des Desasters

1. Der Consultant schrieb das Pflichtenheft und der Kunde sah, dass es gut war. Der Kunde war so erfreut über diese Reflektion der letzten Workshops und der zahlreichen Besprechungen in typisierter, stilistisch korrekter Schriftform, dass ihn dies über alle Maße erfreute und so unterzeichnete das Dokument mit seiner vollen Hingabe und einer Leichtigkeit, die dem Fall eines Furzes im Wind gleichkam.
2. Der Consultant überreichte dem Programmierer das geheiligte und unterzeichnete Pflichtenheft mit einer heroischen Geste, die seine ganze Pracht und seinen ganzen Glanz im Licht der aufgehenden Sonne widerspiegelte und der Programmierer weinte Tränen des Glückes, als er das sauber spezifizierte und unterschriebene Dokument sah. Er hob seine Arme mit dem Dokument in seinen Händen gen Himmel und ihm war, als würde er Engelschöre singen und himmelhoch jauchzen hören, ein metaphorisches Schwingen erfasste ihn und er wusste, das dies ein gutes Projekt werden würde.
3. Der Programmierer weinte bittere Tränen der Scham, denn er schämte sich seiner stillen Vorwürfe und bösen Gedanken, die er gegen das Wort „auspezifiziert“ in Zusammenhang mit dem Wort „Pflichtenheft“ hegte, denn er sah, das es gut war.
4. Und so implementierte der Programmierer die Software anhand der Spezifikation des strahlenden Pflichtenheftes und er wurde wir geplant in Time and Budget fertig, was nicht nur seinem Umsatz, sondern auch seinem Ego zugute kam und der Programmierer sah, dass es wirklich gut war.
5. Und die Qualitätssicherung testete die vom Programmierer implementierte Software anhand des glorreichen, epochalen Pflichtenheftes und sie war erstaunt darüber, dass sie weder den Programmierer noch den Consultant zu verschiedensten Themen des Pflichtenheftes mehrfach befragen musste, sondern sich alles wie von selbst erklärte. Und die Qualitätssicherung weinte Tränen der Freude, da sie das Pflichtenheft ohne einen einzigen FogBugz Case guten Gewissens abzeichnen konnte.
6. Der Programmierer überreichte dem Consultant den glorreichen Updater, der alle Änderungen und Anpassungen des Pflichtenheftes beinhaltete, mit einem feierlichen Paukenschlag und der Consultant reichte ihn mit einer Geste der Verzückung weiter an den Kunden und installierte ihn zusammen mit dem Kunden vor Ort.
7. Doch plötzlich zogen dunkle Wolken am Firmament auf, denn das was der Kunde sah, enttäuschte ihn bitterlich. Er interpretierte die Spezifikation anders als der Consultant und der Programmierer es taten. Und er wurde wütend, denn der er hatte sich doch so gut mit dem Consultant abgestimmt und nun hatte das Traumschloss Risse bekommen..
   

Die Bäche aus Milch verwandelten sich in Bäche aus Scheiße, wo gerade noch Dönerteller vom Himmel flogen, waren es nun wieder verbrannte Stücke dieser ekelhaften Pizza, kurz und gut: Der Traum zerplatzte wie eine Seifenblase.

So weit so gut, bzw. wie in diesem Fall so weit, so Sch.... (Wiederholungen machen das Wort auch nicht besser). Ein relativ normales Projekt mit einer postsuccessiven, feingranularen Phase der Anpassung. Wenn man so denken, hat man sich gerade als Consultant der übelsten Sorte geoutet – was ja auch kein Beinbruch ist. ODER ?

Was macht man also in so einem – täglich vorkommenden Falles des Missverständnisses? Man passt das Pflichtenheft an, richtig.

Und genau an dieser Stelle greift dann der retroperpektivische Negationseffekt.

Konsequenz

Man nehme einmal an, der Kunde wollte Feature A implementiert haben. Feature A wurde vom Programmierer mit einem Implementierungsaufwand von 10 Tagen betitelt. Der Programmierer wird pünktlich fertig, das Feature wird ausgeliefert, der Kunde fängt an zu kotzen, weil es nicht seinen ach so klar formulierten und unterzeichneten Anforderungen entsprach, und Consultant und Kunde setzten sich erneut zusammen (Stichwort: Deeskalationsmanagement, mmmh geil…) und waren sich diesmal wirklich einig, dass beide jetzt auf denselben Nenner gekommen sind. Das Pflichtenheft wurde angepasst.

Jetzt kommt der Haken an der Sache:
Da das Feature vom Programmierer damals mit 20 Tagen betitelt wurde, die Änderungen aber nochmals 10 Tage in Anspruch nehmen, was nach Adam Riese 30 Tage macht und der Kunde aber keinesfalls bereit ist, die 10 Tage Mehraufwand zu tragen, kommt der Consultant also eines bis dahin vielleicht noch schönen Tages zum Programmierer und sagt etwas, wie :„Ich hab noch mal mit dem Kunden gesprochen, er will das Feature so und so lieber haben, ich hab Dir das hier im Pflichtenheft nachspezifiziert.“

Und der Programmierer sagt zum Consultant: Mh, okay kann ich machen, sind dann zusammen 30 Tage für die Implementierung, bezahlt der Kunde das denn auch?

Consultant:"Das können wir ihm unmöglich in Rechnung stellen, da wurde halt aneinander vorbei geredet und keinem ist es aufgefallen. Sag mal, damals, als Du Feature A entwickelt hast, hast Du doch auch nicht wirklich 20 Tage dafür gebraucht. Du warst doch nach 10 Tagen bereits schon fertig und hast dann andere Sachen vorgezogen, oder?"
"Nein, habe ich nicht" daraufhin der Programmierer.

Langes, tiefes Schweigen beiderseits.

Dies war also der Versuch, den retroperspektivischen Negationseffekt an den Mann zu bringen. Netter Versuch. Und wieder einmal kann man sagen,

„Je länger es her ist, desto weniger aufwändig war es“