Digital > Fefes Blog 2.0 > a80f1acf
  Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting]  Mittwoch, 23 März 2016 | Blog: 2 | No: 35174     feed-image

Aus einer Einsendung zu Defect Management:

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.

[zurück] [ältere Posting][neuere Posting]
[zurück] [ältere Posting][neuere Posting]

Fefes Latest Youtube Video Links