Wie kann ich meinen Manager davon überzeugen, dass wir die technische Verschuldung reduzieren müssen?

Question

view on stackexchange narkive permalink

Ich arbeite als Entwickler an einem 15 Jahre alten Softwareprodukt, das seit all der Zeit kontinuierlich weiterentwickelt wird. Die Codebasis ist enorm. Wir haben über 500 MB Code, von dem ich vermute, dass er mehrere Millionen Codezeilen umfasst. Davon ausgenommen sind Bilder oder die Datenbank mit über 500 Tabellen. Die Nachfrage nach einer Erweiterung des Codes ist hoch. Kunden möchten ständig neue Funktionen sehen. Das ist natürlich nicht gut für die technische Verschuldung. Die Programmierer scherzten oft, dass etwas, dessen Erstellung in einer normalen Codebasis eine Stunde dauern würde, bei uns eine Woche dauert. Es wird erwartet, dass ein neuer Programmierer mehr als ein Jahr benötigt, um sich mit einem Modul vertraut zu machen. Das obere Management möchte, dass wir die Leistung der Software verbessern, und hat das untere Management angewiesen, dies zu tun. Dies ist jedoch im Ticketsystem nicht direkt sichtbar.

Ich arbeite mit vier anderen in einem der Entwicklungsteams Programmierer und ein Manager. Drei von uns glauben, dass viel Refactoring notwendig ist, zumindest in den Teilen, die häufig verwendet und weiterentwickelt werden. Einer der anderen Programmierer, der seit Beginn des Programms an dem Programm arbeitet, und der Manager sind dagegen. Sie sind jedoch aus verschiedenen Gründen dagegen. Der Manager glaubt nicht, dass Code-Refactoring oder eine andere Reduzierung der technischen Schulden den Kunden oder den Zahlen unseres Teams hilft (was seinen Gehaltsscheck beeinflussen kann), während der andere Programmierer glaubt, dass ein Großteil des Codes bereits perfekt ist und Variablen und Funktionen aufweist sind böse und sollten vermieden werden. Der andere Programmierer ist nicht älter als der Rest von uns, hat aber am längsten hier gearbeitet. Es gibt einen leitenden Entwickler, der an einem anderen Modul arbeitet, das nicht von diesem Manager verwaltet wird und den wir möglicherweise für unsere Sache rekrutieren können.

Im Laufe der Jahre haben sich auch die Kundenerwartungen geändert. Obwohl es ihnen gut ging, dass ein Modul vor 15 Jahren 5 Minuten brauchte, sind sie mit dieser Zeit derzeit nicht zufrieden. Ich denke, es kann viel gewonnen werden. Ich habe eine Stunde damit verbracht, eine einzelne Funktion zu überarbeiten, die ich vor einiger Zeit sowieso erweitert habe, wodurch die Ladezeit eines Prozesses von 10 Minuten auf 10 Sekunden reduziert wurde. Andere Teams arbeiten daran, die technische Verschuldung zu reduzieren, was die Leistung erhöht, Fehler reduziert und die Expansionsfähigkeit erhöht. Unser Team ist das einzige Team, das dies nicht tut. Wir sind das "beste" Team im Ticket-Dashboard, da wir die meisten Tickets gelöst haben. Für das obere Management ist die Leistung derzeit das wichtigste Problem. Ein Teil ihrer Lösung besteht darin, den Code in eine neuere Sprache zu verschieben, damit er tatsächlich (als Einheit) getestet werden kann, da ein Großteil des alten Codes noch nie getestet wurde und Kunden bei einem Upgrade auf 64-Bit-Systeme versagen.

Wie kann ich (und die beiden anderen Programmierer) unseren Manager (und den anderen Programmierer) davon überzeugen, dass wir an technischen Schulden arbeiten müssen?

Ich möchte das hervorheben Das obere Management ist der Ansicht, dass wir an der Leistung arbeiten müssen, hat jedoch bestimmte Ziele nicht veröffentlicht. Mein Manager hingegen konzentriert sich auf Zahlen, die direkt im Ticket-Dashboard angezeigt werden. Die Leistung ist hauptsächlich schlecht, da Abfragen überall sind und oft öfter als nötig ausgeführt werden. Ich habe vorgeschlagen, Abfragen zu bearbeiten und sie in separate Funktionen oder Klassen zu verschieben, aber das Hauptproblem ist, dass der andere Entwickler nicht an Klassen oder Funktionen glaubt und der Manager ihm vertraut.

Answer 1

view on stackexchange narkive permalink

Die Situation, in der Sie sich befinden, ist nicht eindeutig und nicht unangemessen. Es ist eigentlich ziemlich Standard in der produktionsbasierten Softwareentwicklung. Es gibt einige Punkte, die besonders berücksichtigt werden sollten:

1. Technische Schulden sind unermesslich. Sie können eine Funktion nicht untersuchen und "quantifizieren", wie viele technische Schulden vorhanden sind oder wie viel Geld es dir nicht bringt. Sie können es versuchen, aber am Ende machen die Zahlen keinen Sinn oder spielen keine Rolle. Ähnlich wie Sie sich eine Funktion nicht ansehen und nicht sagen können, wie viele Fehler es gibt (was eine wörtliche Frage ist, die mir kürzlich gestellt wurde). Der Grund, warum Unternehmen "Funktionen vor Korrekturen" priorisieren, liegt darin, dass Kunden ihnen sagen, "wir werden Sie anstelle der anderen Personen verwenden, wenn Sie dies und das hinzufügen." Technische Schulden tragen nicht dazu bei, daher müssen Sie einen Weg finden, sie zu verkaufen.
2. Unternehmen arbeiten mit Einnahmen. In der IT- / Software-Entwicklung verstehen wir das oft falsch oder vergessen Sie dies, aber ein Unternehmen muss Geld verdienen , um zu überleben. Das heißt, es muss einen Weg finden, Kosten zu senken oder Gewinne zu steigern. Ein umfangreiches Refactoring (bei dem Sie nicht mehr an neuen Funktionen arbeiten) führt dies nicht aus. Was Sie tun müssen, ist zu beweisen, dass Sie umgestalten und Gewinne sparen oder steigern können.
3. Refactoring (also Schuldenabbau) ist ohnehin Teil des regulären Prozesses. Wenn Sie daran arbeiten Als Funktion sollten Sie immer die technische Verschuldung dort umgestalten und reduzieren, wie Sie sich dort befinden , nicht als Nachdenken. Das Problem ist, dass niemand solche Dinge getan hat, als er es das erste Mal gebaut hat. Sie sind also das, was Sie als "zwischen einem Felsen und einem harten Ort" bezeichnen könnten. Daher denken Sie, dass die einzige Option darin besteht, einen großen Refactor durchzuführen. aber es ist nicht das einzige . Jedes Mal, wenn Sie eine Funktion berühren, sollten Sie ein wenig umgestalten. Es ist nur ein Teil des Entwicklungsprozesses.
ol>

---

Also, was können Sie tun?

Ich werde Ihnen aufgrund meiner Erfahrung Ratschläge geben, die es mir ermöglichten, ein Finanzdienstleistungsunternehmen davon zu überzeugen, mir das gesamte dritte Quartal (Juli, August, September) zur Überarbeitung unserer Webanwendung zur Verfügung zu stellen. Wir haben es mit einer 20 Jahre alten Anwendung zu tun, die Auftritte und Auftritte von Code enthält (die neuesten Schätzungen für die Zeilenanzahl liegen bei über 200 Millionen). Ich überzeugte sie, mir drei Monate Zeit zu geben (lassen Sie die anderen Teams ihr Ding machen, aber meine drei Monate), um das Notwendige wieder aufzubauen. Es war nicht einfach und deins auch nicht, aber es hat mir ein paar wertvolle Lektionen beigebracht.

Zunächst einmal, wie in einer anderen Antwort erwähnt, der ROI-Analyse . Überlegen Sie, wie Sie abschätzen und nachweisen können, welche Vorteile wir durch spezielle Refactoring-Perioden erzielen können. Sie müssen nicht riesig sein. Wenn Sie nachweisen können, dass 1 Stunde Entwicklungszeit jedes Mal, wenn sie geladen wird, 9 Minuten weniger als eine Last benötigt, ist dies ein guter Anfang , besonders wenn es sich um eine stark frequentierte Funktion / ein Modul / was auch immer handelt. (Verwenden Sie diese Funktion, die Sie bereits überarbeitet haben, als Proof-of-Concept.)

Zweitens formulieren Sie Ihre Anfrage neu, sodass Sie die Geschäftsvorteile angeben. stark> Ich hasse es, es zu sagen, aber wenn Sie nicht für ein Unternehmen arbeiten, das in letzter Zeit zu den "Startups" gehört, ist es Ihrem Chef egal, wie Sie sich dabei fühlen. Ihr Chef wird sich darum kümmern, wie Sie damit Geld verdienen können. Finden Sie heraus (möglicherweise vom Vertrieb, vom Kundendienst usw.), welche Ladezeiten die Kunden stören, und beschreiben Sie, wie wir dies beheben können, um die Kundenzufriedenheit zu steigern. (Sie sind sich nicht sicher, wie spezialisiert Ihre Software ist, aber ein Teil der von mir erstellten Software ist branchenspezifisch. Daher ist Mundpropaganda enorm. Wenn Sie also Ihren Kunden helfen können, sie besser zu mögen, werden sie es vielleicht sagen ihre Freunde.)

Drittens "beschweren" Sie sich nicht über den aktuellen Status quo. Nicht "jammern", nicht "aufregen", sachlich sprechen. Ihre Manager sind viel eher empfänglich, wenn Sie ohne Emotionen mit ihnen sprechen und Fakten nur positiv darlegen. Nicht "dieser Code ist Mist", sondern "hier können wir einige taktische Vorteile erzielen." Sprechen Sie nicht darüber, wie so und so schlechten Code schreibt. Sprechen Sie nicht darüber, wie so und so gegen die Idee ist. Sprechen Sie über die Vorteile. Halte das Gespräch positiv. (Ich weiß, wie schwierig das ist, aber es ist oft eine gute Sache, sich auf die Zunge zu beißen.)

Viertens, sprechen Sie mit der Entwicklerzeit, die gespart wird, und wie das sein kann angewendet auf andere Projekte / Probleme. Wie sieht Ihr Rückstand aus? Wächst es ständig? Schieben Sie die Dinge für immer mehr Zeit ab? Sprechen Sie darüber, wie sich dies darauf auswirken kann (und wird). Wenn das Unternehmen von neuen Funktionen profitiert, sprechen Sie darüber, wie Sie Zeit haben, die neuen Funktionen schneller zu erstellen. Sprechen Sie darüber, wie dies Entwickler beschleunigen wird.

Fünftens, und das klingt vielleicht so, als wäre ich ein "Idiot", aber sprechen Sie nicht darüber, wie "es den Entwicklern das Leben leichter machen wird . " ^{1 sup> Ich hasse es, schlechte Nachrichten zu überbringen, aber Ihren Managern ist es oft egal, wie sich die Entwickler fühlen. Wir sind in den meisten Organisationen eine "Produktions" -Rolle, das heißt, wir tun alles, um Geld zu verdienen, ähnlich wie Lagerarbeiter für Logistikunternehmen. Wenn Sie nicht, wie bereits erwähnt, für ein Unternehmen arbeiten, das sich grundlegend unterscheidet, wird das Management nicht oft zu viel Aufwand in das "Entwicklerglück" investieren. Lassen Sie diesen Gedanken ganz fallen und sprechen Sie darüber, was und warum das Unternehmen von Ihrer Idee profitiert.}

Und schließlich sollten Sie verstehen, dass, wenn dies eine alte Anwendung ist und Umbauten bereits in Arbeit sind, die beste Option darin besteht, sie einfach "aufzusaugen" und zu hoffen, dass die Dinge besser werden. Wenn sie bereits an einer neuen Version arbeiten, erhält Ihr Team nicht die Ressourcen oder die Zeit, die Sie möchten. Sie betrachten Ihr Team als "Triage" -Team. Sie müssen sicherstellen, dass die aktuelle Version lange genug steht, um die neue Version zu erstellen. Ja, es ist scheiße, aber so funktionieren die Dinge. Ich war in vielen Triage-Teams und die meisten von ihnen haben ein ziemlich geringes Glück und einen hohen Turnaround, aber es ist das Leben. Das Geschäft kümmert sich nicht darum, denn Ihre Aufgabe ist es, das aktuelle so billig wie möglich am Laufen zu halten. Es ist traurig, aber fast vorteilhaft, einen hohen Turnaround zu haben, da dies bedeutet, dass die Gehälter viel niedriger sind.

^{1 sup>: In einigen Regionen der Welt herrscht derzeit "Entwicklermangel", was bedeutet, dass sie nicht über genügend Ersatzentwickler verfügen, um die aktuellen Rollen zu besetzen, ganz zu schweigen von neuen. In einigen dieser Fälle nehmen die Unternehmen die Zufriedenheit der Entwickler ernst. Das war nicht meine Erfahrung, und ich schreibe diese Antwort aus meiner Erfahrung. Daher kann Ihr Kilometerstand in diesem Teil des Themas (manchmal erheblich) variieren.}

Answer 2

view on stackexchange narkive permalink

Natürlich gibt es Vor- und Nachteile.

Sie sehen dies als technische Schuld an, weil es viel Code und viele Daten gibt.

Auf der anderen Seite der Medaille: Es sieht nicht so aus, als ob irgendetwas an dem System, das gerade funktioniert, unbedingt falsch ist. Es macht den Job, den es machen soll - das Unternehmen bei der Erzielung von Gewinn zu unterstützen.

Wie bereits erwähnt, führt die Einrichtung eines Programms zur Umgestaltung des Codes an sich zu technischen Schulden in Bezug auf Analyse und Umgestaltung , erneutes Testen und erneutes Bereitstellen eines Systems, das bereits funktioniert. Je größer das System ist, das überarbeitet wird, desto größer ist das Risiko für das Unternehmen.

Der Kompromiss besteht darin, nur die Teile, an denen aktiv gearbeitet wird, innerhalb relativ enger Grenzen umzugestalten. Daher sind Analyse und Test eingeschränkt in jedem Projekt.

Andernfalls werden Sie die Menschen in jahrelange Anstrengungen einbinden, in denen das Unternehmen den Nutzen nicht wirklich sieht.

Ich weiß, dass dies nicht der Fall ist. t die Antwort, nach der Sie fragen, aber sie ist realistisch und dies (meiner Meinung nach) wirtschaftlich sinnvoll.

Im Moment scheint es einige Arbeitsabläufe zu geben, die auf die Kundennachfrage reagieren in Bezug auf die Leistung. Sie haben noch keine der gleichen Anfragen erhalten, also können Sie nur warten und Ihre zugewiesenen Arbeitsaufgaben so effizient wie möglich gestalten.

Sie können Ihre ausführen eigene Analyse und Verbesserungsvorschläge, die jedoch nur von den Managern genehmigt werden können, je nachdem, welche Prioritäten das Unternehmen für das gesamte System hat.

Answer 3

view on stackexchange narkive permalink

Kurze Antwort: Sie können es nicht tun.

Lange Antwort: Das Management ist am Geschäftswert interessiert, Sie können keine technischen Schulden verkaufen. Sie können jedoch eine Reduzierung der QS-Kosten durch Testautomatisierung oder Modularisierung verkaufen, wenn dies dazu führt, dass jedes Modul separat verkauft wird. Sprechen Sie einfach ihre Sprache!

Hinweis für Sie: Ein Manager ist ein professioneller Lügner. Was für Sie ein 15-jähriger Müllhaufen ist, präsentiert er als 15-jährige Erfolgsgeschichte der Lieferung in Industriestandardqualität. Wenn ein Manager etwas Unbestimmtes sagt wie "glauben, dass wir an der Leistung arbeiten müssen", ist dies nur eine BS, um Sie glücklich und konform zu machen. Wenn ein Manager etwas erledigen muss, ist dies ein Fälligkeitsdatum und eine Person, die für die Lieferung verantwortlich ist. Ihr Team ist "das Beste". Das bedeutet, dass jede Änderung des Workflows Ihres Teams gegen das Interesse des Unternehmens verstößt und energisch bekämpft wird. Da dies den Gehaltsscheck des Managers beeinflusst, werden Sie nicht nur als Feind des Unternehmens, sondern auch als persönlicher Feind mit Wagemut betrachtet Konsequenzen.

Es ist erwähnenswert, dass das Management nicht daran interessiert ist, wenn Sie kleine Fehler machen oder Refactoring durchführen, wenn Sie Fehler beheben und neue Funktionen hinzufügen. Sie interessieren sich für KPI, die sie vierteljährlich oder jährlich in ihren Präsentationen zeigen.

Wenn Sie also Ihr Leben als Entwickler durch die Verbesserung der Codebasis vereinfachen möchten, tun Sie dies einfach heimlich, ohne das Management zu benachrichtigen.

Answer 4

view on stackexchange narkive permalink

Eine Lösung besteht darin, dass sich auch Tickets für technische Schulden im Dashboard befinden sollten. Eine andere Lösung besteht darin, dass die Leistung eine Metrik auf höchster Ebene sein sollte, an der alle Teams gemessen werden.

Ich stimme zu, dass Refactoring nur von begrenztem Nutzen ist und wahrscheinlich aktiv gefährlich ist, wenn Sie keine Unit-Tests durchführen. Das Hinzufügen von Komponententests könnte einfacher zu verkaufen sein, da dies die Zuverlässigkeit für alle erhöht.

Wenn dies jedoch die Einstellung Ihres Managers ist, ändert sich dies im Allgemeinen nur sehr langsam und der Prozess wird wahrscheinlich frustrierend sein. Vielleicht würden Sie gut daran tun, das Team zu wechseln?

Answer 5

view on stackexchange narkive permalink

Ich kann aus Erfahrung darüber sprechen.

Vor Jahren war ich der Hauptprogrammierer für ein bekanntes Mainframe-Produkt (Comparex). Der Code im Basisprogramm bestand aus verwickelten Spaghetti, und jeder Versuch, ihn zu ändern, würde drei andere Dinge zerstören.

Die Veröffentlichungszyklen lagen etwa ein Jahr auseinander. Es gab einen großen Rückstand an angeforderten Änderungen, aber nur wenige wurden jedes Jahr durchgeführt. Also habe ich das gesamte Programm durchgesehen und es in ein strukturiertes Format konvertiert.

Das war eine große Aufgabe. Ich musste tatsächlich Tools entwickeln, um den Code zu analysieren und zu dokumentieren, welche Routinen welche aufgerufen haben. Ich habe schließlich alle bis auf 3 nicht strukturierte Zweige beseitigt.

Jetzt war der größte Teil des Entwicklungszyklus vorbei, als ich damit fertig war. Also habe ich einige Änderungen in der Anforderungswarteschlange implementiert und sie gingen so schnell ein, dass ich in diesem Jahr eine "normale" Anzahl von Upgrades durchführen konnte, obwohl ich so viel Zeit für die Umstrukturierung des Programms aufgewendet habe.

Die nächstes Jahr konnte ich Änderungen immer noch schnell implementieren und den Anforderungsstau vollständig beseitigen.

Answer 6

view on stackexchange narkive permalink

Sie müssen den Business Case aufschreiben und den Return on Investment (ROI) anzeigen. Die meisten Geschäftsentscheidungen laufen auf Geld hinaus. Sie müssen zeigen, dass durch Refactoring die Entwicklung in Zukunft für immer um XX% beschleunigt wird oder dass kein zusätzlicher Entwickler oder beides erforderlich ist, die Produktivität jedoch für XX Monate um XX% verringert wird. Wenn Sie dies tun können, werden sie möglicherweise mit Refactoring an Bord kommen. ABER

1. Ohne Komponententests wird es schwierig, vorhandene Funktionen nicht zu beschädigen.
2. Refactoring liefert bessere Ergebnisse für die verbesserte Produktivität / Qualität
ol>

Vergessen Sie niemals, dass der Zweck der Softwareentwicklung in fast allen Unternehmen darin besteht, Einnahmen zu generieren oder Ausgaben zu senken. Stellen Sie sicher, dass Ihr Vorschlag diese beiden Punkte abdeckt und es nicht besonders schwierig sein sollte, einen Fall zu vertreten. ABER Ihr Management möchte dies möglicherweise immer noch nicht tun, wenn es befürchtet, dass die Projektionen erheblich abweichen, da dies sie ihren Job kosten könnte.

Answer 7

view on stackexchange narkive permalink

Wir sind alle bis zu einem gewissen Grad in diesem Boot. Es ist unwahrscheinlich, dass Beschwerden helfen - Sie werden nur als jemand eingestuft, der nicht versteht, dass Dinge schnell erledigt werden müssen, und Ihr Rat wird ignoriert.

Die Sache ist, dass die meisten Programmierer dies nicht tun Ich denke, sie haben die "Berechtigung", eine Korrektur korrekt durchzuführen, wenn dies nicht der direkteste Weg ist, um das Problem zu lösen (z. B. ein Tool zum Überprüfen der Datenbankkonsistenz oder zum Bearbeiten von Systemdaten erstellen). Alles, was wiederholt Zeit benötigt und automatisiert werden kann, sollte Sei automatisiert - du bist ein Programmierer, oder?

Sie haben nicht nur die Erlaubnis, die Dinge richtig zu machen, sondern müssen dies auch. Dies liegt in der Natur Ihres Jobs und Ihr Manager ist möglicherweise nicht in der Lage, die Faktoren zu verstehen, sondern wenn Sie sich nur die Zeit dafür nehmen Richtig und beschwere dich nicht, sie werden dich wahrscheinlich nicht stören. Wenn Manager oder hartnäckige Programmierer diesen Ansatz nicht verstehen und aktiv gegen Sie kämpfen können, suchen Sie nach einem anderen Job.

Sie können Ihren Teamkollegen auch helfen, zu verstehen, dass sie Änderungen auf die richtige Weise implementieren können. Es kann zu einer Kultur mit subtilem, aber kontinuierlichem Push werden.

Wenn es um größere Korrekturen wie eine Startzeit von 5 Minuten geht, senden Sie diese als Fehler und überarbeiten Sie den Code, wenn Sie an dem Fehler arbeiten Verbessern Sie es, während Sie dort sind.

Mit der Zeit sollten Sie das Team werden, das Lösungen am schnellsten liefert (Wenn nicht, führen Sie nicht die richtigen Refactors durch, da Sie sagten, ein einwöchiger Job sollte ein paar dauern Stunden, wenn Sie ein bisschen aufgeräumt haben) und dann mehr Spielraum und die Möglichkeit haben, umfassendere Änderungen vorzunehmen.

Ich empfehle, niemals zu sagen, dass wir alles neu schreiben müssen. Riesige Projekte wie dieses dauern fast immer viel länger als erwartet und / oder scheitern und können dabei einige Jobs oder das gesamte Unternehmen kosten.

Answer 8

view on stackexchange narkive permalink

Einfache Antwort: Sie können eine so große Codebasis nicht von Grund auf aufgeben und neu schreiben. Das wäre eine selbstmörderische Geschäftsentscheidung.

Was Sie jedoch tun können, ist einen Plan für das Schreiben von besserem Code für die Zukunft auszuarbeiten.

Sie und die anderen Entwickler müssen sich etwas einfallen lassen Ein Plan für die Codierungsstruktur, an den sich alle halten werden.

Sie müssen sich diese einhorn-utopische Umgebung vorstellen und mit jedem Ticket, das Ihnen in den Weg kommt, danach streben.

Ja, es muss mit dem aktuellen "Greuel" koexistieren, aber wenn Sie Aufgaben und Tickets erhalten, arbeiten Sie diese weiter in die Utopie ein.

Sobald der neue Code überprüft wurde und Wenn Sie nach Spezifikation arbeiten, können Sie veraltete Codeteile entfernen.

Stellen Sie sich das so vor. Wenn ein Kunde einen Maler beauftragt, eine Tür zu streichen, ist es dem Kunden egal, ob der Maler einen 2-Zoll-Pinsel, einen 3-Zoll-Pinsel oder eine kleine Kombination aus Walze und Pinsel verwendet. Wenn die Farbe auf die Tür gelangt, ist sie ein Erfolg.

Answer 9

view on stackexchange narkive permalink

Fügen Sie ein weiteres Argument hinzu, um Ihren Pitch vorzubereiten.

Es gibt eine Frage zu diesem Stapel Wie kann man Leute dazu bringen, an sehr alten und veralteten Technologien zu arbeiten?, die kürzlich gestellt wurden. Ich würde vorschlagen, dass sich das Unternehmen möglicherweise nicht jetzt, aber ohne Änderung der Prozesse, in 5 Jahren an einem Ort befindet, an dem es Menschen, die ihren Code verstehen und bereit sind, ihn sich überhaupt anzusehen, hohe Gehälter zahlen muss.

Wenn ein neuer Entwickler ein Jahr benötigt, um sich mit der Codebasis vertraut zu machen, bedeutet dies, dass das Unternehmen bei einem Rücktritt von 10% der Mitarbeiter einige Monate benötigt, um Ersatz zu finden, und ein Jahr, um sie als produktiv zu betrachten als das verlorene Personal. Das könnten sogar anderthalb Jahre von 10% Produktivitätsverlust sein. Wenn das Unternehmen nicht groß ist und derzeit 40 Entwickler an dem Code arbeiten, sind 10% nur 4 Personen.

Answer 10

view on stackexchange narkive permalink

Ich denke, das kann ein langsamer Prozess sein. Fragen Sie, ob neue Projekte mit Unit-Tests und Modernisierung geschrieben werden können, und erklären Sie, dass dadurch die Funktionalität sichergestellt wird. Letztendlich wird das Management feststellen, dass dies von Vorteil ist, da Codes leicht geändert werden können und möglicherweise andere Teile der Anwendung "auf den neuesten Stand gebracht" werden.

Im Moment kämpfen Sie gegen Selbstzufriedenheit. Die Software funktioniert und die Entwicklung dauert Wochen , ist aber erledigt. Jeder kann argumentieren, dass Software nicht ewig hält, so dass das nicht funktionierende 64-Bit-System leicht verworfen werden kann und "in Arbeit" ist. Wenn Sie zeigen können, dass anstelle von Wochen dies in Tagen erfolgen kann oder dass Sie problemlos Code für 64-Bit portieren können, ist dies hilfreich.

Answer 11

view on stackexchange narkive permalink

1. Erstellen Sie einen "Business Case" - ein Beweis dafür, dass der Abbau technischer Schulden Ihrem Unternehmen einen Wert von $$$ bringt. Verwenden Sie explizite Datenpunkte, um Ihren Fall zu beweisen.
2. Kommunizieren Sie den Vorschlag. Machen Sie Ihre Nachricht kurz, Manager haben keine Zeit für "TL; DR" -Texte. Wenn Sie Ihre Idee in 5 Sekunden aufstellen könnten und wenn sie sinnvoll ist und mit den organisatorischen Zielen übereinstimmt, wird der Manager nach Details fragen.
ol>

Ich hoffe das hilft.

Answer 12

view on stackexchange narkive permalink

Meine Empfehlung: Wenn Sie einen Fehler beheben oder eine Funktion hinzufügen müssen und in einem Bereich des Codes arbeiten, belassen Sie diesen Bereich in einem besseren Zustand als jetzt. Wenn Sie aufgrund der schlechten Qualität Ihres Codes viel mehr Zeit für Änderungen aufwenden, als Sie sollten, bedeutet dies keine spürbare Zeit für Ihre Arbeit und hilft beim nächsten Mal in diesem Bereich.

Und ich würde Ihrem Chef einen Rat geben: Wenn Ihr Code nicht auf einem 64-Bit-System ausgeführt wird, werden Sie bald große Schmerzen haben. In meiner Region ist Folgendes passiert: In den letzten zwei Jahren konnten Sie keine iOS-Apps veröffentlichen, die 64-Bit nicht unterstützen. Wenn Ihre Benutzer iOS 11 verwenden (die aktuelle Version für einige Monate), werden 32-Bit-Apps nicht ausgeführt. MacOS ist etwas zurückgeblieben, aber Benutzer erhalten jetzt Warnungen (wodurch Sie viele teure Supportanrufe erhalten), und in der nächsten MacOS-Version wird die 32-Bit-Unterstützung weg sein.

Windows ist etwas langsamer, aber es gibt sehr gute technische Gründe, 32-Bit-Apps nicht zuzulassen. Und wenn das passiert und Sie keine funktionierende App haben, ist Ihr Chef in Schwierigkeiten (Sie sind es nicht, weil er Sie brauchen wird). Sagen Sie Ihren Kunden, dass sie kein Upgrade auf Windows 12 durchführen können. Schlimmer noch, sie können defekte Computer nicht ersetzen, wenn neue mit Windows 12 ausgeliefert werden.