Aus einer Einsendung zu Defect Management:

Aktuelle bin ich im Startup, hier ist das ganz anders, hier suchen wir gerade verzweifelt nach einem Messias der uns Hoffnung gibt unter dem technischen Schuldenberg nicht zu ersticken. Wir sprechen von dem einen großen Refactoring in etwa so wie von der Wiederkunft des Herrn.

Nurnoch dieses Feature, dieser Bug-Fix, dann haben wir Zeit fürs Refactoring, wo wir mit einem "stabilen Kern" anfangen, weg von diesem Code Sediment das sich am Boden der wechselnden Anforderungen abgesetzt hat.

 

Das gelobte Land der Microservice Infrastruktur ist gleich hinter der nächsten Ranz-Library Einbettung die man ja nur als Brückenlösung hat bis es dann endlich soweit sein wird. Alles kleiner, leichter, simpler, test getrieben entwickelt, vorher gut durch konzipiert… ich bin mir sicher wir werden auch die nächste Architektur, wenn sie denn kommt, schnell ans Kreuz schlagen, weil ein Judas uns von Reactive Programming vorschwärmt.

 

Das war auch ein wiederkehrendes Thema in den Einsendungen, dass in vielen Projekten so hohes Risiko gefahren wird, dass das Risiko durch die Bugs im Vergleich zum Risiko, dass gleich die ganze Firma stirbt, weil das Geschäftsmodell nicht funktioniert, vernachlässigbar gering sind. Das scheint bei Startups geradezu üblich zu sein, dass die erste Version scheiße ist. Wenn das bei den Kunden ankommt, dann haben wir ja genug Venture-Kapital, um fähige Experten reinzuholen, die können das dann aufräumen.

Das scheint das aktuelle Muster zu sein, wie es zu Legacy-Problemen in der Codebasis kommt. Traditionell kommen Legacy-Codebasen eher davon, dass die Entwickler es damals halt nicht besser wussten — also alle Entwickler jetzt, nicht nur die an diesem Projekt gearbeitet haben.

 

Ich hörte auch ein paar Mal davon, dass firmeninterne Schuldzuweisungen und Angst vor Karriereknick durch Fehlermachen dazu führen, dass man für alle tatsächlichen Codeänderungen Externe reinholt. Denen kann man dann die Schuld geben, wenn was nicht läuft. Klar hilft das der Firma und dem Projekt genau gar nicht weiter, eher im Gegenteil. Denn die Externen haben ja keine langfristigen Probleme zu befürchten, wenn sie Mist machen. Daher wird da im Allgemeinen ungeniert von Stackoverflow und co zusammengeguttenbergt, was das Zeug hält.

 

Und in einigen Projekten kommt es sogar vor, dass verwendete Libraries gar nicht im Quellcode vorliegen. Der ist verloren gegangen, oder man hatte ihn nie. Oder man hat ihn noch, aber die Autoren arbeiten hier nicht mehr und haben keine Dokumentation hinterlassen und keiner versteht den Code.

 

Das hört sich alles an wie lustige Lagerfeuer-Anekdoten, Opa erzählt aus dem Krieg und so, aber das scheint alles wirklich und tatsächlich immer und immer wieder zu passieren.

 

Update: Die paar Einsendungen, die von "bei uns werden alle Bugs so schnell wir können gefixt" erzählten, erzählen übereinstimmend, dass die Kunden es lieben und ohne Ende dankbar sind, einmal im Leben nicht über den Tisch gezogen zu werden. Ist ja auch irgendwie klar.

Ich glaube, ich habe noch zu keiner Umfrage so viele Einsendungen gekriegt wie zu der mit Defect Management. Ich bin noch nicht mal ansatzweise durch mit den ganzen Mails. Aber einige Sachen stechen heraus.

Erstens: Fast immer heißt es "keine Zeit". Auch in Abwandlung als "andere Sachen sind wichtiger". Wir reden hier also von einer BWL-Betrachtung der Situation. Da kommen dann so Argument wie "der Kunde hat ja schon gezahlt". Wieso sollte ich mich um Bugs kümmern, nachdem der Kunde gezahlt hat? Wichtiger ist es, neue Kunden zu gewinnen.

 

Daraus folgt dann spannenderweise direkt ein Argument für Abo-Modelle, SaaS und Cloud Computing. In den Fällen, würde man ja denken, hat der Betreiber einen direkten Anreiz, seinen Scheiß stabil zu kriegen. Denn er schadet sich nur selber, wenn es nicht stabil ist.

 

Aber dem gegenüber stehen dann Einsendungen aus der Spielebranche. So F2P- und Browserspiele meine ich jetzt. Die haben ja nun "wir schaden uns nur selbst" als Extrem, sozusagen in Reinform. Dem Argument folgend müssten die ja alle Bugs immer sofort fixen. Tun sie aber nicht. Im Gegenteil, da bleibt auch alles liegen. Deren Metriken sind die Rate der neu angelegten Accounts und die reinkommende Kohle pro Tag. Das heißt, dass die Bugs ganz schnell schließen, mit denen man beispielsweise bescheißen kann, oder den Server abstürzen lassen kann. Die zweite Reihe sind Bugs, mit denen man andere Leute ärgern kann. Die werden auch gefixt, aber nur, wenn sie außen bekannt werden und weiträumig ausgenutzt werden.

 

Wir haben hier also keinesfalls die Situation, dass "der Markt das dann schon richten wird", wenn man das rein ökonomisch bewertet alles.

 

Andere strukturelle Probleme, die immer wieder angeführt werden, sind Ausschreibungen. Das Konzept der Ausschreibung führt dazu, dass der Billigste gewinnt, und der ist nur deshalb so billig, weil er kein Budget für Fehlerbereinigung zurücklegt. Mehrere Einsender schreiben sogar, dass Fehler absichtlich eingebaut wurden, damit man auch noch einen Support-Vertrag verkaufen kann, und über den dann die Differenz zwischen der Ausschreibung und den realen Kosten wieder reinholen kann.

 

Ein weiteres wiederkehrendes Element sind unnötige Grabenkämpfe. Die Tester fühlen sich von den Entwicklern vorgeführt und ignoriert. Die Entwickler fühlen sich von Testern und Management gegängelt. Das Management spart die Tester am liebsten ganz ein und macht den Entwicklern uninformierte Vorgaben. Gerne wird auch über Vertriebler geschimpft, die Dinge verkauft haben, die gar nicht einlösbar sind.

 

Ich glaube, dass man hier auf allen Seiten das Verhalten ändern muss. Das Management hat die Aufgabe, Geld zu sparen, und "Prozesse zu optimieren". Bis es schmerzt. Ob es schmerzt oder nicht, das brauchen sie als negatives Feedback. Und es muss für sie klar erkennbar sein, dass das jetzt zuviel "optimiert" war. Die Entwickler verhalten sich aber häufig dumm in der Situation und versuchen, die unmöglichen Vorgaben einzuhalten. Dabei wird der Code schlechter und schlechter, ein Legacy-Schuldenberg baut sich auf, und die Bugs kommen beim Management aber nicht als "das liegt an deiner Sparpolitik" an sondern als "die Entwickler sind inkompetent und undiszipliniert" an — und die machen dann weiter mit der "Kostenoptimierung".

 

Und was das Management falsch macht ist, dass sie keine Risiken eingehen. Man muss die Management-Hierarchie als Risiko-Puffer betrachten. Das Management unten und die Entwickler, die sollen Risiken eingehen. Die sollen keine unsauberen Abkürzungen nehmen. Aber wenn sich eine Gelegenheit bietet, mit einer anderen Technik besser zu sein, dann sollen sie das machen. Das untere Management hat genau die Aufgabe, das zu begleiten, und die Reißleine zu ziehen, wenn das schief läuft. Und das Management darüber ist dafür da, solche Fehlversuche dann zu kompensieren. In der Realität gibt das untere Management Kritik direkt an die Entwickler weiter, die sind dann verunsichert und machen lieber gar nichts, bevor sie was falsch machen, und das Ergebnis ist für alle Scheiße.

 

Entwickler müssen verstehen, dass sie gemanaged werden, nicht befehligt. Essentieller Teil von Management ist, dass man beobachten kann, wenn etwas falsch läuft, und dann gegensteuert. Entwickler, die schlechte Nachrichten nicht an das Management weiterleiten, und technische Schuld auftürmen, um dem Management zu gefallen, sabotieren damit das System und ruinieren die Firma.

 

Oh, eine strukturelle Sache habe ich noch: "Das ist doch nur ein Prototyp / end of life / wir rollen demnächst Version 2 aus, da muss man doch jetzt keine Arbeit mehr investieren". Und dann scheitert das Ausrollen der Nachfolgeversion und man hat sich selbst in den Fuß geschossen.

 

Auch "the guy left"-Szenarien scheinen erschütternd häufig vorzukommen. Und Teil von dem oben erwähnten Konkurrenzdenken ist auch, dass man dann Kosten externalisiert. "Ich muss das nicht fixen, wenn es einen Workaround gibt. Mit dem schlägt sich dann das Support-Team herum, nicht wir."

 

Die Heilsversprechen von Scrum und co haben sich in der Realität nur partiell manifestieren können. Bei einigen scheint das gut zu klappen, bei anderen führt es zu Burnout durch den hohen Druck und der totalen Transparenz, bei wieder anderen gibt es für Bugfixes keine Punkte im Sprint, daher macht es niemand, und bei noch anderen fallen Bugs unter den Tisch, weil man ihren Aufwand schlechter abschätzen kann als für Neuentwicklungen.

 

Update: Oh und: So 5% der Einsender widersprechen meiner Prämisse, dass das Management grundlegend versteht, dass Bugs nicht fixen die Sache schlimmer macht.

 

Update: Es waren dann doch auch mehr als nur einer dabei, die sagten, dass sie alle Bugs fixen, und zwar so schnell wie sie können.