Frage:
Wie kann ich meinen Manager davon überzeugen, dass wir die technische Verschuldung reduzieren müssen?
Belle
2018-07-16 14:10:06 UTC
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.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/80254/discussion-on-question-by-belle-sophie-how-can-i-convince-my-manager-that-wir-nee).
Mögliches Duplikat von [Wie kann ich meinem Chef zeigen, dass das Streben nach schnellen Gewinnen mehr Probleme verursacht als löst?] (Https://workplace.stackexchange.com/questions/19406/how-can-i-show-my-Chef, der nur nach schnellen Gewinnen strebt, verursacht mehr Probleme)
Zwölf antworten:
#1
+85
Der Kommissar
2018-07-16 18:56:10 UTC
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.
  4. 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.

Obwohl ich den meisten Ihrer Beiträge zustimme, ist das Argument "Es wird Entwickler glücklich machen" in meinem Teil der Welt (Westeuropa) ein sehr, sehr starkes Argument.Angesichts des Mangels an Entwicklern werden die Unternehmen extreme Anstrengungen unternehmen, um sie bei Laune zu halten.Warum sollte ein Unternehmen, das Baumhäuser (mit einer Folie!) Für Besprechungen baut, 10% (oder mehr) der Arbeitszeit für unterhaltsame Nebenprojekte zulässt und buchstäblich Millionen für die Rekrutierung ausgibt, ohne sich um das Glück der Entwickler zu kümmern?
@Douwe Typischerweise ist es in den USA genau das Gegenteil.Ich werde der Antwort einen Klappentext hinzufügen, wenn ich Zeit habe.
@202_accepted Keine Ahnung, wo Sie gearbeitet haben, aber Google ist dafür bekannt, dass es seinen Mitarbeitern 20% ihrer Freizeit gibt, um an dem zu arbeiten, woran sie interessiert sind - nicht weil dies die optimale Art ist, ihre Zeit zu verbringen, sondern weil es die Zufriedenheit der Entwickler erhöht.Die meisten Unternehmen, von denen ich weiß, dass sie Geld ausgeben, um ihre Entwickler glücklich zu machen ... Vielleicht möchten Sie sich in Ihrem wahrscheinlich wahnsinnig teuren Stuhl zurücklehnen, während Sie die kostenlosen Snacks und Getränke genießen, während Sie diesen Kommentar lesen.
@Voo Ich habe noch nie für ein solches Unternehmen gearbeitet, war aber in den Bereichen Finanzsicherheit, Finanzdienstleistungen, Pharmazie und Universität (Softwareentwicklung) in den USA tätig.Ich kann nicht für Ihr Unternehmen sprechen, ich kann nur für mein Unternehmen sprechen, aber "Zufriedenheit / Glück der Entwickler" zur Sprache zu bringen, war meiner Erfahrung nach nie ein erfolgreiches Argument.Wenn Sie eine andere Erfahrung haben, empfehle ich Ihnen, daraus eine Antwort zu machen.Statistisch gesehen sind Google, Microsoft, Amazon und Facebook in dieser Situation Ausreißer.Die meisten Unternehmen haben kein Kapital in Milliardenhöhe.
Die Art und Weise, wie Sie es in Ihrer Antwort geschrieben haben, impliziert, dass Sie beide gleichzeitig ausführen können, und unterscheidet sich stark von dem, was Sie in diesem Kommentar geschrieben haben.Sie sollten diese Formulierung besser in Ihre Antwort aufnehmen, als zu streiten.
Es ist eigentlich nicht wahr, dass Sie die technische Verschuldung nicht quantifizieren können - dieses Buch [Software Design X-Rays von Adam Tornhill] (https://smile.amazon.com/Software-Design-X-Rays-Technical-Behavioral/dp/1680502727 / ref = sr_1_2? S = books & ie = UTF8 & qid = 1531775152 & sr = 1-2) zeigt, wie (es gibt wahrscheinlich auch andere Bücher / Papiere, die ebenfalls helfen können) und wie Sie Ihre Energien bei der Verbesserung Ihres Systems auf die Bereiche lenken können, dieverursachen die meisten organisatorischen Schmerzen.
Es wäre auch gut, die Risiken der Einführung neuer Fehler beim Refactoring hervorzuheben, selbst mit dem Sicherheitsnetz von Unit-Tests.
"Programmierer das Leben leichter machen" macht sie produktiver.Ein Unternehmen sollte alles tun, um das Leben des Programmierers zu erleichtern.Als würde man Zeit damit verbringen, Software einfacher zu modifizieren, wenn sich diese Zeit amortisiert.
Sechstens ist Abrieb ein besonders wirksamer Weg, um das Management davon zu überzeugen, dass technische Schulden ein Problem darstellen.Mit anderen Worten, geh.Jeder Arbeitnehmer, der einen neuen Arbeitsplatz findet, kündigt und geht, ist möglicherweise einfacher als die Lösung des Problems.Wie schlimm kann es werden?Sehr schlecht.Hier ist ein Artikel über ein Unternehmen, das bis 2012+ einen IBM 402 verwendet hat: https://www.pcworld.com/article/249951/computers/if-it-aint-broke-dont-fix-it-ancient-computers-in-use-today.html.Einige Orte warten buchstäblich, bis sie vom Computer History Museum an die Tür geklopft werden, bevor sie aktualisiert werden.
@gnasher729 Ich stimme zu, aber meiner Erfahrung nach ist dies nicht der Fall.In der Softwareentwicklung in "Produktionsqualität" (Erstellen von Inhalten für Kunden, nicht für interne Tools) werden diese normalerweise als weitaus weniger wichtig angesehen.Es ist einfacher, den Entwickler zu ersetzen und zu hoffen, dass es funktioniert.(Auch diese Antwort stammt aus meiner Erfahrung. Ich habe als Produktionsingenieur für ein halbes Dutzend verschiedener Softwareunternehmen gearbeitet, und dies sind die Informationen, die für mich konsequent gearbeitet haben.)
@teego1967 ** Absolut nicht **.Ich werde diesen Rat unter keinen Umständen OP empfehlen.In erster Linie fragt OP nicht nach Alternativen, sondern nach Möglichkeiten, das Management zu überzeugen.Was passiert, wenn sie OPs Bluff callen?Zweitens, das heißt meiner Meinung nach "aufgeben", und ich bin nicht groß darin aufzugeben.Sehen Sie es bis zum Ende durch.Drittens gehe ich nur dann den Weg "drohen zu beenden", wenn ich eine Alternative habe, die ansteht und bereit ist zu gehen, weil es sonst sehr gefährlich wird.
@202_accepted, Ich habe nicht "drohen" gesagt, um aufzuhören.Ich sagte aufhören.Kein Bluffen.Das OP kann nur so viele Dinge ausprobieren, dass es sich lohnt, sie davon zu überzeugen, die Richtung zu ändern.Aber "saugen es auf" oder die Nase an den Schleifstein zu legen, ist für Märtyrer und kann Karrierewege beschädigen.
"Technische Schulden sind unermesslich".Technische Schulden sind ein Aufschub dessen, was Sie heute bis morgen tun können.Es dauert oft länger, es morgen zu tun, weil sich die Dinge bis dahin geändert haben werden.Es spielt keine Rolle, ob es behoben ist, Fehler, neue Funktionen, Upgrades, Migrationen usw. usw. Es ist einfach der Akt des Verschiebens.Die Messung des Aufwands, um diese Dinge zu tun, ist ein völlig anderes Thema, aber es hat mehr mit Schätzung und Projektplanung zu tun als mit technischen Schulden.Ich denke, es ist ein schlechter Rat, den Leuten zu sagen, dass es nicht wie an einer Regel gemessen werden kann.
Beachten Sie, dass kampferprobter Code hässlich und von unschätzbarem Wert ist.Joel hat es gut ausgedrückt - https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
#2
+19
user44108
2018-07-16 14:21:00 UTC
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.

Nur um einige Dinge zu klären: Ich glaube nicht, dass die Menge an Code technische Schulden macht.Ich denke, die Qualität ist gut, zumal es keine Tests gibt und es noch nie getestet wurde.Ich habe mich für ein kleines Refactoring ausgesprochen, wie das Umschreiben einer einzelnen Funktion, um besser lesbar und schneller zu sein, wenn diese Funktion sowieso erweitert wird.Es gibt keine Tests für die alte Codebasis und sie können nicht erstellt werden.Logic soll auf den neueren Anwendungsserver gehen, der in einer neueren Sprache geschrieben ist und geringfügige Änderungen erfordert, aber der Manager erlaubt uns nicht, daran zu arbeiten.
Grundsätzlich fordert er uns auf, die Unternehmensrichtlinien zu ignorieren.
Das klassische Beispiel für diesen Irrtum ist wahrscheinlich Netscape - sie haben den Weg beschritten, ihre alternde, kanteröse Codebasis für ein vollständiges Umschreiben zu verschrotten.Die neue Version litt unter extremen Verzögerungen, da sie von Grund auf neu geschrieben wurde und im Gegensatz zu stabilem Produktionscode Unmengen von Fehlern in der Kindheit aufwies, deren Beseitigung lange dauerte.Am Ende hatten sie einen großartigen, sauberen und modernisierten Code, aber in der Zwischenzeit verloren sie ihre Benutzerbasis vollständig, die zu anderen Lösungen überging, und Netscape starb.Der Umgang mit Legacy-Code kann die geschäftlichen Konsequenzen radikaler Maßnahmen nicht ignorieren.
"Es sieht nicht so aus, als ob irgendetwas an dem System, das gerade funktioniert, unbedingt falsch ist." Außer das OP sagt, "es schlägt auf 64-Bit-Systemen fehl".
@Belle-Sophie "er sagt uns, wir sollen die Unternehmensrichtlinien ignorieren" Haben Sie das schriftlich?Wenn in der Unternehmensrichtlinie "Refactor for Efficiency" steht und er mündlich "Mach dir keine Sorgen um Effizienz" sagt ... Üben Sie CYA, indem Sie ihn diese Anfrage schriftlich stellen lassen?
#3
+11
meopemuk
2018-07-16 17:15:27 UTC
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.

#4
+7
Alper
2018-07-16 15:11:21 UTC
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?

Ich mag diese Lösung.Ich kann nur einen Tick vergeben, der zur Antwort von 202 ging, die viele Vorschläge enthält, aber Ihre ist definitiv meine zweite bevorzugte Antwort.Ich werde vorschlagen, Performance-Tickets in der Sitzung der Textabteilung zu eröffnen.
Ich denke, was noch besser wäre, wäre, nach jedem Ticket Pre-Post-Benchmarks für einige Kernmetriken durchzuführen und die Akzeptanzkriterien für jedes Ticket um Leistung zu verbessern.Das ist ziemlich hartnäckig, aber wenn es wirklich wichtig ist, könnte es gerechtfertigt werden.
#5
+7
Jennifer
2018-07-17 13:04:22 UTC
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.

#6
+4
UnhandledExcepSean
2018-07-16 18:11:42 UTC
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
  3. 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.

#7
+2
Bill K
2018-07-16 23:08:24 UTC
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.

#8
+1
MonkeyZeus
2018-07-16 21:26:18 UTC
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.

#9
+1
Zefiryn
2018-07-17 02:51:08 UTC
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.

#10
  0
Dan
2018-07-16 21:36:24 UTC
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.

#11
  0
Vladimir Kroz
2018-07-17 11:51:30 UTC
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.
  3. ol>

    Ich hoffe das hilft.

#12
  0
gnasher729
2018-07-17 12:04:53 UTC
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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...