Auf mich hört ja keiner ...

[Sven Rautenberg]

Moin!

Meiner Erfahrung nach kommt Müll hauptsächlich durch zwei Dinge zu Stande:

1. der Entwickler hat keine Ahnung davon was er eigentlich tut

Das geht ja auch auf mehreren Ebenen: Entweder die Anforderungen sind unklar, oder der Entwickler ist der Aufgabe nicht gewachsen, weil ihm Erfahrung, Wissen und/oder Können fehlen.

2. der Entwickler leidet unter enormem Zeitdruck und muss "schnell schnell" alles fertigbekommen, kann sich die Zeit aber nicht dafür nehmen.

An dieser Stelle ist der Entwickler auf einer ganz anderen Ebene gefordert, als zur Entwicklung: Er muss, wenn er seinen Job und sich selbst ernst nimmt, klar gegenhalten, wenn ein Terminwunsch nicht geht. Er muss NEIN sagen.

Insbesondere muss er NEIN sagen, NEIN meinen, und dann diese Aussage auch durchhalten. Wenn er NEIN sagt, es dann aber dennoch versucht, und dann scheitert, ist er der Doofe. Wenn er NEIN sagt, trotz hohem Drucks, und sein Chef glaubt ihm nicht, dann ist der Chef der Doofe, weil er trotz gegenteiliger Aussage nach außen kommuniziert hat, es ginge doch.

Und der Chef hat in diesem Fall auch die Chance verspielt, die wahren Interessen hinter dem Termindruck zu ermitteln und zu erforschen, was zu dem Termin tatsächlich geliefert werden soll - und warum.

In beiden Fällen sieht man, ob der Entwickler wenigstens gute Ideen gehabt hat, die man weiterverfolgen kann.

Wenn ein Entwickler unter Zeitdruck, weil er nicht NEIN sagen konnte, irgendwas zusammengecodet hat, dürfte die beste initiale Struktur durch diese Aktion recht untrennbar zu einem unansehnlichen Codemüll zusammengebacken worden sein. Das wieder sauber aufzutrennen ist eine sehr schwierige und aufwendige Aufgabe.

Ob der Entwickler tatsächlich eine Null ist oder eben nur unvollständig gearbeitet hat erkennt man daran, dass die grundlegenden Teile sauber ausgearbeitet sind, der Rest aber dreckig drangebaut wurde.

Da mag der Entwickler schuld sein, vllt. aber auch der Auftraggeber, der nach 20 mal nachfragen immer noch nicht richtig definieren konnte.

Das ist auch ein großes Problem: es wird eine Anforderung definiert, daran wird dann 3 Monate programmiert und danach kommt der Auftraggeber drauf, dass er doch alles ganz anders braucht - das erschüttert die Struktur der Software in ihren Grundfesten und ohne alles neu zu schreiben kommt man einfach nicht drum rum, dass man "schnell schnell" in 2 Tagen die Arbeit von 2 Monaten erledigt.

Wenn es die Struktur der Software in ihren Grundfesten erschüttern kann, weil ein Feature nicht so wie anfänglich geplant umgesetzt werden soll, war vermutlich mit der Struktur was falsch.

Und wenn die neue Anforderung nicht problemlos in den Code hineingetan werden kann, war vielleicht auch mit der Software-Entwicklungs-Methodik was falsch.

Ja - und besonders schwierig ist es im Projektgeschäft, dann ein Feature auszubauen, welches er haben wollte und jetzt nicht mehr braucht, weil du einen drauf lassen kannst, dass er es drei Wochen später doch wieder braucht. Du stehst also vor einem Dilemma: bereinigst du den Code, wird er das Feature wieder haben wollen und darfst es wieder dazubauen - belässt du es im Code, wird er es nie wieder haben wollen und dein Nachfolger wird sich über den "Trottel der den Code nicht aufräumt" wundern :)

Und wenn ein nicht mehr benötigtes Feature nicht ohne Angst, dass man zuviel entfernt und deshalb Dinge kaputt macht, wieder herausgenommen werden kann, dann hat man vielleicht keine funktionierenden Tests.

Aber im Grund gib ich dir Recht, es ist schon ein nettes Gefühl, wenn man zu 100% sagen kann. "Das hab ich euch so vor 2 Jahren gesagt". Wenn Kollegen daneben hocken und dann sagen können "Ja das hat er". Dann ist das doch Gefühlt, wie 2 Beförderungen xD

So ist es - nur leider kommt das selten vor.

Und was bringt das dann genau? Ok, kommt natürlich auf die Situation an, aber in der Regel ist es doch so:

Entwickler hat eine gut begründete Position, wie eine Anforderung in Software umzusetzen ist.

Chef hat die Argumente gehört und sich anders entschieden.

Und der Lauf der Dinge hat bewiesen, dass der Entwickler richtig lag und der Chef falsch.

Und jetzt kommentiert der Entwickler die damalige Chef-Entscheidung mit "Hab ich gleich gesagt, dass das ein Fehler war.", und alle Fachkollegen stimmen ihm zu.

In welcher Situation ist jetzt der Chef? Und inwiefern hilft das dem Team bei der nächsten Entscheidung dieser Art? Warum wird vom Entwickler mit dem Finger auf den Chef gezeigt und gemeint: "Du da hast den Fehler gemacht. Du bist Schuld!"

Wenn solch ein Verhalten zur Unternehmenskultur gehört, dann bedeutet das umgekehrt auch, dass der Chef bei der nächsten Situation, bei der es genau umgekehrt läuft, dann mit dem Finger auf den Entwickler zeigt und sagt: "Du hast die Software scheiße programmiert. Du bist Schuld!"

Und weil er Chef ist und vermutlich die Macht dazu hat, kann er den Entwickler bei ausreichender Anzahl solcher Vorfälle dann auch mal rauswerfen. Oder zumindest sanktionieren.

Ich möchte nicht in einem Umfeld als Entwickler arbeiten, in dem Fingerpointing und Schuldzuweisungen an der Tagesordnung sind und man am besten lebt, wenn man keine Fehlentscheidungen trifft, weil man am besten gar keine Entscheidungen trifft.

Software zu entwickeln ist Teamwork. Das bedeutet: Das Team als Gesamtheit ist verantwortlich für die geleistete Arbeit und die abgelieferte Qualität. Niemand kann alleine Schuld sein, denn wenn das Team in Ordnung findet, dass Mitarbeiter A die Aufgabe B erledigt, und niemand hinterher kontrolliert, ob das nach dem gemeinsamen Qualitätsempfinden vernünftig gebaut wurde, muss das Team damit leben, wenn sich hinterher rausstellt, dass das eben doch nicht so war. Das fortwährende Versagen des Teams bei der Definition und Kontrolle eigener Qualitätsstandards führt dazu, dass jeder nur so für sich codet, irgendeine beliebige Qualität abliefert, und damit möglicherweise zu genau diesem Exemplar von $VORGAENGER wird, dessen Code niemand mehr anfassen will.

Vermutlich sind in solchem Umfeld die Entwickler auch lieber Einzelkämpfer und Herrscher über "ihren" Code, den niemand anderes anfassen darf - was auch kein Teamwork ist, sondern Wissensmachtkampf, entweder motiviert durch die Gewissheit, "die können micht nicht rauswerfen, ohne selbst unterzugehen", oder aus Angst, dass die eigenen Unzulänglichkeiten ruchbar werden. Den Schaden hat in allen Fällen das Team insgesamt und der Auftraggeber, denn im ersten Fall wird die Chance verpasst, Spezialwissen breiter zu streuen, um in die Lage zu kommen, eben genau nicht von einer einzelnen Person abhängig zu sein (selbst wenn man denjenigen nie rauswerfen wollte, gibts immer unbeeinflussbare Faktoren wie Unfälle, Krankheiten oder Urlaub, oder unerwarteten erhöhten Arbeitsanfall). Im zweiten Fall wird die Chance verpasst, sich selbst durch Feedback der Kollegen weiterzuentwickeln.

Keine dieser Verhaltensweisen würde ich als sonderlich professionell bezeichnen.

- Sven Rautenberg