Die Schuld für die Übel von heute ist die technische Schuld von gestern

Bei einer Anwendung, die ich derzeit unterstütze und die ich ursprünglich nicht geschrieben habe, sind überraschend viele Probleme hinsichtlich Qualität, Skalierbarkeit und Auslastung aufgetreten. Zum Glück habe ich neue Projekte, die ich von Grund auf unternommen habe, um meinen gesunden Menschenverstand zu bewahren.

Das ursprüngliche Team bestand aus 20 einigen Entwicklern (die meisten mit veralteten Kenntnissen), keine Geschäftsanforderungsdokumente oder Qualitätssicherungstester, und wurde von Anfang an in einer Art Wasserfall schlecht verwaltet. Die Anfänge der Produktion waren ein peinlicher Albtraum, in dem brüchiger prozeduraler Code mit noch brüchigeren Korrekturen gepatcht wurde. Später wurden Features hinzugefügt, die in ein Datenmodell eingeschlüsselt wurden, das sie nie unterstützen sollte, und es ist nicht ungewöhnlich, dass derselbe Code zehnmal dupliziert wird und dass Ressourcen nicht sicher geschlossen werden und ORM-Abfragen nur Zehntausende von Entitäten abrufen alles bis auf eine Handvoll rausschmeißen.

Ich bin es jetzt und jedes Mal, wenn ein neues Problem auftaucht, schreibe ich ein Modul auf bessere Standards um und mache es VIEL stabiler, aber das Management braucht eine angemessene Erklärung, warum all dies vorkommt.

Sie scheinen schockiert und verwirrt über die Vorstellung, dass diese Anwendung von schlechter Qualität ist und in technischen Schulden versinkt. Glücklicherweise verstehen sie das Konzept der technischen Verschuldung und unterstützen mich bei meinem Bestreben, sie auszurotten, und sie unterstützen mich sehr und schätzen mich, aber ich habe das Gefühl, ich beschuldige immer nur das ursprüngliche Team (das alle ein anderes Projekt in einem anderen ruiniert haben) Teilung).

Das Fazit ist, dass ich nicht "That Guy" sein möchte, der sich immer über die Entwickler des Projekts beschwert. Ich habe diese Einstellung schon einmal bei Leuten in meiner Karriere gesehen, die ich persönlich als unwissend empfand und nicht die Umstände und Designeinflüsse berücksichtigte, die die Dinge ermutigten, so zu sein, wie sie waren.

Normalerweise sehe ich diese Haltung darin, das vorherige Team für schlechtes Design und schlechte Implementierung von idealistischen Nachwuchsentwicklern verantwortlich zu machen, die nicht die Lebenserfahrungen hatten, die mehr hochrangige Mitglieder hatten und von denen sie profitierten.

Haben Sie das Gefühl, dass es eine bessere, vielleicht auch sanftere Möglichkeit gibt, dem Management derartige Probleme zu melden, ohne den Ruf der Person / des Teams vor Ihnen zu beeinträchtigen?

Technische Schulden sind wie finanzielle Schulden. Sie nehmen es (hoffentlich) strategisch in die Entwicklung eines Programms mit der Absicht auf, dass es sich in Zukunft auszahlt. Manchmal treffen die Leute schlechte Entscheidungen über technische Schulden (wie das Aufladen einer Kreditkarte), aber manchmal ist ein gewisser Betrag an technischen Schulden ganz normal. Die Entscheidung, heute nicht die Zeit dafür zu verwenden, etwas "richtig" zu machen, mit der Annahme, dass es in Zukunft geändert werden muss, ist völlig normal und sollte vorweggenommen werden. Natürlich gibt es eine feine Linie, aber der Gedanke, dass Sie es beim ersten Mal richtig machen, kann seine eigenen Probleme verursachen (Analyse-Lähmung).

Unter dem Strich muss jedes nicht-triviale Projekt, das länger als ein paar Jahre dauert, einige Zeit für die Neuentwicklung aufgewendet werden, um die technischen Schulden abzubauen. Die Sache ist, dass dies auch dann zutrifft, wenn Sie Ihre Bewerbung richtig schreiben . Wenn Sie dies nicht tun, häufen Sie Schulden an, und das Management kann das mit Sicherheit verstehen, wenn Sie es so darstellen.

Erklären Sie dies dem Management, und anstatt das vorherige Team die ganze Zeit "zu beschuldigen", können Sie dies als "Business as usual" präsentieren.

IMO gehen Sie das meistens schon richtig an: Sie schlagen kein Ground-up-Rewrite vor, weil "der alte Code scheiße ist", sondern Sie beheben eins nach dem anderen.

Um zu vermeiden, dass Sie das alte Team beschuldigen, stellen Sie sich vor, dass dieser Code wahrscheinlich unter hohem Zeitdruck erstellt werden musste. Das Management hat das damals wahrscheinlich nicht wirklich verstanden, nur weil der Code "more or less works" nicht bedeutet, dass jede Wartung ohne viel Aufwand und Nacharbeit möglich ist.

Schätzen Sie das alte Team, das es geschafft hat, ein Produkt herzustellen, das tatsächlich einen geschäftlichen Nutzen bringt - es würde nicht mehr verwendet werden, wenn es nicht wäre. Sie werden überrascht sein, wie oft ein Projekt keinen geschäftlichen Nutzen bringt, auch wenn es schön geschrieben ist.

Wenn ich gefragt werde, ob ich einen Kommentar zum aktuellen Status eines Problemprodukts abgeben möchte, greife ich immer auf "es ist, was es ist" zurück und beginne dann, über Pläne zur Verbesserung des Produkts zu sprechen.

Sie kennen nicht alle Faktoren, die zu der Entscheidung geführt haben, die dieses Problem verursacht hat - vielleicht waren sie damals sogar vernünftig. Alles, was Sie tun können, ist voranzukommen und die Dinge morgen zu verbessern. Und es hört sich so an, als ob Sie einen guten Job machen - Sie haben die richtige Einstellung für diese Situation.

Konzentrieren Sie sich darauf, nur Fakten zu melden, wenn Sie gefragt werden. Sie müssen keine Erzählungen oder Kommentare hinzufügen. Sagen Sie einfach "das System schlägt in Fall X fehl" oder "die Berichte sind für Fall Y falsch." Fügen Sie dann schnell hinzu, wie Sie die aktuelle Situation verbessern möchten.