Wie kann ich das Management vom Umgang mit technischen Schulden überzeugen?


158

Diese Frage stelle ich mir oft, wenn ich mit Entwicklern zusammenarbeite. Bisher habe ich in vier Unternehmen gearbeitet und festgestellt, dass es mir an Aufmerksamkeit mangelt, Code sauber zu halten und mit technischen Schulden umzugehen, die zukünftige Fortschritte in einer Software-App behindern. Zum Beispiel hatte die erste Firma, für die ich arbeitete, eine Datenbank von Grund auf neu geschrieben, anstatt etwas wie MySQL zu verwenden, und das hat dem Team die Hölle bereitet, wenn es die Anwendung umgestaltet oder erweitert hat. Ich habe immer versucht, ehrlich und klar mit meinem Manager umzugehen, wenn er Projektionen bespricht, aber das Management scheint nicht daran interessiert zu sein, das zu reparieren, was bereits da ist, und es ist schrecklich zu sehen, wie sich das auf die Moral des Teams auswirkt.

Was denken Sie über den besten Weg, um dieses Problem anzugehen? Was ich gesehen habe, sind Leute, die packen und gehen. Das Unternehmen wird dann zu einer Drehtür, in der Entwickler ein- und aussteigen und den Code verschlimmern. Wie teilen Sie dies dem Management mit, damit es Interesse daran hat, technische Schulden auszuräumen ?


5
"Zusammenarbeit mit Entwicklern" "Teilen Sie dies dem Management mit" Nach was fragen Sie? Entwickler oder Manager? Wer ist das Verhalten, das Sie ändern möchten?
S.Lott

45
Technische Schulden sind wie Finanzschulden - es ist auf lange Sicht viel einfacher, sie einfach nicht zu akkumulieren. Zahlen Sie alle Ihre technischen Rechnungen einmal pro Woche.
Lawrence Dol

7
Mike> Ich denke, Sie leben in einer viel weniger restriktiven Welt, da Fristen und begrenzte Budgets die Welt dominieren, in der ich lebe. Wenn Software sich nicht gut an zukünftige Bedürfnisse anpasst und viel Arbeit erfordert, um sie zu beheben, ist das Management oft mehr damit beschäftigt, sie zu ignorieren es und schrauben auf Funktionen. Jetzt haben viele Unternehmen, für die ich gearbeitet habe, Arbeitszeittabellen erstellt, damit Entwickler ihre Arbeit aufzeichnen können. Wenn keine Zeit investiert wird, in die das Management das potenzielle Geschäft sieht, verschwenden Sie Ihre Zeit.
Desolate Planet

4
Man könnte sagen, es ist ein Problem mit kurzfristigen Vorteilen im Vergleich zu langfristigen Vorteilen. Wenn ein Softwareteam ein System so aufgeräumt hat, dass die Implementierung neuer Funktionen weniger als eine Stunde statt eines Tages dauerte, ist dies ein unmittelbarer Vorteil. Wenn das Management sieht, dass Sie versuchen, den Code zu verbessern und gegen das verstoßen, was sie wollen, sind Sie in ihren Augen ein bisschen rebellisch. Ich weiß wirklich nicht, was die beste Lösung ist, aber es scheint ein so verbreitetes Problem zu sein, und ich habe gesehen, was es für Teams bedeutet.
Desolate Planet

3
Scott> Um die Frage zu beantworten, möchte ich die Haltung des Managements ändern. Entwickler kennen den Code und wissen aus erster Hand, welcher Code verbessert werden muss, um die Arbeit zu erleichtern. In einem früheren Job, als wir eine neue Version einer App herausbrachten, nahm die Anzahl der Bugs immer mehr zu. Ich habe mich sehr bemüht, Teststrategien einzuführen, aber es fühlt sich oft wie eine verlorene Sache an.
Desolate Planet

Antworten:


191

Als ich mich mit meinem Chef traf, um dies zu besprechen, sagte er, ich solle das Refactoring in alle meine Schätzungen einbeziehen. Er sagte, dass es kein Problem ist, über das er nachdenken möchte. Stattdessen sollte ich damit umgehen.

Dies ist kein Problem, über das das Management im Allgemeinen nachdenken möchte. Sie sind nicht die Ingenieure, Sie sind. Machen Sie dies einfach zu einem unausgesprochenen Teil Ihrer Schätzungen, und Sie werden feststellen, dass die technische Verschuldung abnimmt.

Es wird jedoch niemals perfekt sein. Technische Schulden sind wie Kreditkartenschulden eine Investition, um Kunden schneller zu erreichen und schneller Marktanteile gegenüber Wettbewerbern zu gewinnen. Wie Kredit, wenn es richtig gehandhabt wird, kann es Sie ziemlich erfolgreich machen.


30
Meine Erfahrung ist in der Regel in diese Richtung. Die technische Verschuldung wird beseitigt, wenn neue Funktionen hinzugefügt werden. Manchmal werden die Schätzungen für bestimmte 'verwandte' Korrekturen / Funktionen aufgefüllt, um diese Dinge zu bereinigen.
Ken Henderson

4
+1 Sie teilen meine Gefühle genau ... außer Sie drückten sich viel diplomatischer aus;)
Michael Brown

7
Gute Antwort. Ich bin noch nicht bei einem Unternehmen, das gerne ein "Refactoring" -Projekt abzeichnet, das dem Kunden keinen Nutzen bringt, sondern nur einen aufgeräumteren Code. Refactor-as-you-go.
JBRWilkinson

7
"Als ich mich mit meinem Chef traf, um dies zu besprechen, sagte er, ich sollte in all meine Schätzungen das Refactoring einbeziehen." - Dies ist die Haltung, die ich einnehme, und die Haltung, die viele Entwickler in Teams einnehmen, in denen ich gearbeitet habe. Wenn sich diese 9 bis 5 Entwickler, wie wir sie nennen, jedoch mit ihren Bewertungen und Gehaltserhöhungen befassen, werden sie nicht mehr Arbeit für sich selbst schaffen. Sie werden folgen, was auch immer das Management denkt, es zahlt sie schließlich.
Desolate Planet

8
@ jmort253: Es gibt ein (geringfügiges) Problem mit dieser ansonsten ausgezeichneten Richtlinie -> es ist nicht möglich, umfangreiche Änderungen vorzunehmen (dh die Datenbank wie vom OP angegeben zu ändern). Diese müssen explizit angesprochen werden.
Matthieu M.

48

Es ist, wie Gandhi sagte, als er gefragt wurde, ob seine Taktik mit jemandem wie Hitler funktionieren würde. Er sagte: "Es wäre schwierig." Aber ich denke, es gibt ein faires Argument, dass die Antwort wirklich "Nein" ist. Leider glaube ich nicht, dass das, was Sie versuchen, getan werden kann. Ich versuche nicht, pessimistisch zu sein, sondern ehrlich zu sein.

Das Problem für mich ist nicht, dass Manager überzeugen müssen. Die Besseren verstehen bereits, dass Schulden ein Mörder sein können, wenn sie nicht verwaltet werden. Aber ob sie es verstehen oder nicht, ob sie gute Manager oder schlechte sind, sie alle stehen unter dem Druck zu liefern, und diese Lieferung wird von ihren Chefs gegen ein Datum beurteilt. Qualität ist nur dann wichtig, wenn sie extrem schlecht ist. In diesem Fall ist es die Schuld der Entwickler. Qualität muss nur "gut genug" sein.

Ich finde es gut, was Renesis in seiner Antwort gesagt hat, weil es eines der wenigen ist, das versteht, dass das Management ganz anders denkt als das Ingenieurwesen. Und ich denke, wir haben alle gesehen, wie sich Unternehmen zu datumsorientierten und projektgesteuerten Unternehmen entwickelt haben, im Gegensatz zu kunden- und qualitätsorientierten Unternehmen. Damit meine ich typische Unternehmen, nicht die wirklich tapferen, die den Mut haben zu sagen: "Es wird erledigt, wenn es erledigt ist" (wie Apple Computer oder id Software - und ja, ich verstehe, dass Menschen manchmal nicht frei sind diesen Ansatz verfolgen).

Aber hier ist die Sache: Unternehmen, die den Quality-First-Ansatz verfolgen ... was fällt Ihnen an ihnen auf? Richtig, sie werden von Ingenieuren geleitet, nicht von Verkäufern, Marketingfachleuten, Projektmanagern oder Buchhaltern. Denken Sie an HP, Apple, ID, Google, Microsoft und IBM. Alles begann und wurde von Ingenieuren erfolgreich gemacht, nicht von Verkäufern, obwohl Verkäufer sicherlich eine Rolle spielten, und ich bin sicher, dass viele darüber diskutieren würden, ob Microsoft mit Qualität in Verbindung gebracht wird :). Und von diesen entkamen diejenigen, die bergab gingen, der ingenieurgetriebenen Führung. Diese Aussage enthält jedoch eine ganze Reihe von Argumenten, da es viele technische Unternehmen gibt, die letztendlich daran gescheitert sind, dass sie sich nicht an veränderte Zeiten anpassen und ihr eigenes Wachstum steuern können. Ich sehe die ingenieurbasierte Führung nicht als Ursache für diese Misserfolge. ' Es geht um Fähigkeiten und Geschäftssinn, die unabhängig davon sind, ob jemand Entwickler oder Buchhalter ist. Generell glaube ich jedoch, dass das Ingenieurwesen den strengen Anforderungen an Rechenschaftspflicht und Disziplin verpflichtet ist, von denen Unternehmen profitieren, in denen das Ingenieurwesen eine Komponente darstellt.

Im Ernst, sieh dich um. Es fehlt dringend die IT-Führung. Der Fokus liegt immer auf Kosten und Zeit und selten auf Qualität, solange dies gut genug ist. IT-Verantwortliche berichten selten mehr an den CEO, jetzt ist es immer der CFO. Die IT-Abteilung bleibt bei der Produktionsunterstützung hängen und ist zunehmend den Projektmanagern verpflichtet, deren Fokus auf kleineren, besser verdaulichen und messbaren Stücken liegt, nicht auf wesentlichen Veränderungen des revolutionären Werts (nicht dass dies notwendigerweise falsch ist; Teilen und Erobern ist eine gute Sache, aber die Vision muss für das große Ganze da sein).

Tut mir leid, dass ich so lange auf diesen Beitrag gewartet habe, aber am Ende denke ich, dass Ihre Frage, wie das Management sich um technische Schulden kümmern soll, oft besser gelöst wird, indem Sie den richtigen Leiter finden, als den vorhandenen zu ändern. Technische Schulden gegenüber Standarddenkern zu erklären, bedeutet, wie Renesis sagte, den Fokus auf Geld und Kosten zu verlagern. Selbst wenn Sie damit erfolgreich wären, wäre es nur wichtig, wenn der Top-Leader des Unternehmens es kauft. Wenn Sie Ihren mittleren Manager davon überzeugen, das Richtige zu tun, wird er wahrscheinlich nur gefeuert.


43

Als Erstes müssen Sie den Wortlaut ändern. Wenn man es "technische Schulden" nennt, entsteht für das Management die Idee, dass es sich um eine Investition handelt - wenn es sich wirklich eher um einen Virus handelt. (Ich bin wie der Dave Ramsey von technischen Schulden.)

Wenn Sie zulassen, dass es unbezahlt bleibt, entstehen enorme Kosten, die nicht leicht zu sehen oder zu beziffern sind.

Listen Sie Probleme wie die folgenden für die Verwaltung auf:

  • Die Schätzungen für neue Funktionen liegen weit über den Anforderungen. Oder überhaupt unmöglich.
  • Fehlerhafter Code erzeugt mehr fehlerhaften Code
  • Die Fehlerliste wächst, auch wenn die Entwickler sie immer reparieren
  • Die Teammitglieder verlassen das Team (dies kann selbst zeigen, dass ein Problem vorliegt, wie in dieser hervorragenden Antwort erläutert ).

7
+1, obwohl ich denke, die letzte Kugel sollte "Die guten / besten Teammitglieder verlassen" sein
Ken Henderson

12
Eine kleine technische Verschuldung ist manchmal eine Investition. Wenn Sie mit einem anderen Unternehmen im Rennen sind und derjenige, der zuerst startet, den Markt für sich selbst erschließt, ist es sinnvoll, Verknüpfungen im Code zu erstellen, um den Start zu beschleunigen. Es wird niemanden interessieren, dass Sie einen perfekten Code haben, wenn Sie null zahlende Kunden haben.
quant_dev

3
@quant_dev Wenn Sie dies als eine Dichotomie zwischen "schneller" und "perfektem Code" sehen, werden Sie natürlich so denken. Es gibt keinen Grund, warum Verknüpfungen nicht technisch einwandfrei sind. In diesem Fall gelten sie nicht als technische Schulden.
Nicole

2
@Renesis "Es gibt keinen Grund, warum Verknüpfungen technisch nicht stichhaltig sein können" - das stimmt einfach nicht.
quant_dev

3
Und manchmal ist es überhaupt keine technische Verschuldung, sondern nur ein Durcheinander: sites.google.com/site/unclebobconsultingllc/…
TrueWill

30

Mein Management hat tatsächlich ernsthafte Anstrengungen unternommen, um technische Schulden abzubauen, was einer der Gründe ist, warum ich gerne dort arbeite, aber es ist eine langfristige Anstrengung und es tut nie weh, sie daran zu erinnern, warum sich die Anstrengung lohnt.

Eine Möglichkeit, den Druck aufrechtzuerhalten, besteht darin, wann immer ich nach einem Kostenvoranschlag gefragt werde, und Zeit zu sparen, wenn ich mich nicht mit bestimmten technischen Schuldenproblemen befassen müsste. Ich beziehe dies in meinen Kostenvoranschlag ein . Zum Beispiel: " Es dauert 2-3 Tage, bis ich diesen Fehler gefunden habe, aber wenn wir bereits zwei andere Fehler mit niedriger Priorität behoben hätten, die schon immer in der Warteschlange standen, würde es wahrscheinlich weniger als einen dauern. " Die Antwort wird darin bestehen, die anderen zu reparieren, während Sie gerade dabei sind.

Ich bin auch mit anderen Antworten einverstanden, wenn es darum geht, Verbesserungen nur als Teil Ihrer Arbeit zu betrachten und sie zu erledigen, wenn dies nicht zu störend ist. Meine derzeitige Aufgabe besteht darin, einen sehr schlecht gestalteten Code zu ergänzen. Anstatt das Chaos zu vergrößern, indem ich meinen neuen Code entsprechend schreibe, verbringe ich ein wenig Zeit damit, die allgemeinen Funktionen zu konsolidieren, sodass das Senden eines Pakets zu einem einzeiligen Funktionsaufruf wird, anstatt ständig 15 Zeilen leicht modifizierter Copy-and- Heizplatte einfügen.

Ich weiß, dass es den Verstand eines Betreuers weiter unten retten wird. Ich weiß es, weil ich heute der Betreuer bin. Ich glaube jedoch auch, dass es meine derzeitige Aufgabe beschleunigen wird, dieses Feature zu integrieren und jetzt zu debuggen.

Eine andere Technik, die ich in der Vergangenheit angewendet habe und die ich noch einmal anwenden sollte, besteht darin , einen umgestaltenden DVCS-Zweig in einem separaten Arbeitsbaum zu speichern , während Sie kompilieren, auf einen langen Test warten oder einfach eine Änderung der Geschwindigkeit benötigen ein bisschen, wenn Sie auf einen Fehler ausgebrannt sind. Solange Sie gelegentlich vom Upstream aus zusammengeführt werden, damit Sie nicht zu weit auseinander gehen, können Sie mit sehr geringem Aufwand so lange wie gewünscht Änderungen überarbeiten. 15 Minuten hier und da pro Tag können sich im Laufe der Zeit wirklich summieren.


20

Sie könnten die Kreditkarten-Analogie ausprobieren. Fragen Sie sie: "Fühlen Sie sich wohl, wenn Sie Ihre Kreditkartenabrechnungen über einen längeren Zeitraum unbezahlt lassen?"

Manager verstehen Kosten und Nutzen, aber (normalerweise) nicht die technischen Begriffe, die von uns Entwicklern verwendet werden. Der Begriff "technische Schulden" wurde bereits erfunden, um diese Kommunikationsbarriere zu überwinden. Möglicherweise müssen Sie ihn jedoch klarer formulieren. Die meisten Manager wissen sehr gut (oft aus eigener Erfahrung), dass überfällige Kreditkartenzahlungen mit einem schrecklichen Zinssatz wachsen, so dass es weh tut , sie unbezahlt zu lassen. Dies kann ihnen helfen, die Schwere des Problems in Bezug auf Software-Entropie zu erkennen.

Aber wenn dies sie nicht überzeugt, versuchen Sie, sachliche Beweise zu sammeln und einige Berechnungen anzustellen. Wie viel kostet es das Unternehmen - sowohl in bar als auch in Form von Zeitverlust -, einen ausscheidenden Mitarbeiter zu ersetzen?


12

Niemand wird Geld dafür geben, etwas zu ersetzen, das mit etwas anderem funktioniert, das (mit etwas Glück) auch funktioniert.

Was Sie tun können, ist vorzuschlagen, es durch etwas zu ersetzen, das mehr bewirkt, dh die Bedienung von technologischen Schulden in einem Upgrade zu bündeln, das sofortige und greifbare Geschäftsvorteile bringt.

Natürlich sollten Sie offen darüber sein, wir sprechen hier nicht davon, es in ein neues Projekt zu "schleichen".

Ich finde die andere Seite, die der Entwickler, schwieriger zu handhaben. Im Grunde läuft es darauf hinaus: Für einige Entwickler ist es eine Frage des professionellen Stolzes, sicherzustellen, dass Ihr Code der bestmögliche Code ist, den Sie entwickeln können. Für andere ist dies nur ein weiterer Job und das Ziel ist es, ihn schnell zu erledigen und nach Hause zu gehen.

Keine Überzeugungsarbeit wird diese Situation ändern, und wenn Sie einen verbindlichen Codequalitätsstandard einführen, werden Ihre neun bis fünf Entwickler einen Weg finden, das System zu betreiben, während Ihre engagierten Entwickler sich unweigerlich über das gesamte Verfahren ärgern werden (was nicht der Fall ist) Sie zielen nicht auf sie, aber Sie können nicht sagen, dass Entwickler X die Regeln einhalten muss, während Y tun kann, was er will.

Was funktioniert, aber dennoch sehr frustrierend sein kann, ist, dass Ihre engagierteren und sachkundigeren Entwickler die Codebasis überwachen. Dies ist wahrscheinlich ein guter Kompromiss zwischen der Weiterentwicklung und dem Aufräumen der vorhandenen Ressourcen.


5
+1 Aber diese 9-5 Entwickler, na ja, Sie wollen die Karusselltür für sie, idealerweise mit irgendeiner Form von Beschleuniger.
Orbling

3
@Orbling: +1. Wenn es ihnen nicht wichtig genug ist, sollten sie wirklich woanders arbeiten. Es ist GROSSARTIG, Entwickler mit "Ich hatte gerade diese Idee ..." zu Ihnen zu kommen.
quick_now

3
@Orbling In bestimmten Entwicklungsbereichen können sie hilfreich sein. Ich bin überhaupt kein Fan von "Entwickler-Snobismus", aber man muss alle Nischen finden, damit sie von Nutzen sind. Das Schlimmste, was Sie tun können, ist anzunehmen, dass jeder so ist wie Sie.
biziclop

Persönlich denke ich, dass die Branche stark überbesetzt ist. Wo ich mich befinde, bewerben sich die meisten Software-Jobs mit gut 300 Bewerbern. Bei diesem Wettbewerbsniveau kann es sich ein Arbeitgeber leisten, Arbeitgeber einzustellen, die überdurchschnittlich gut sind.
Orbling

"Rollen Sie Upgrades in ein Refactoring, um greifbare Vorteile (Verkaufsargumente) zu bieten", höre ich immer wieder von unserem Chefarchitekten.
Mario T. Lanza

12

Tatsache ist, dass in vielen Unternehmen, insbesondere in Anbetracht der aktuellen Wirtschaftslage, jede Stunde an jemanden abgerechnet werden muss.

Oder sie gehen schnell unter .

Es sei denn, die bestehenden Kunden sind bereit, für das Refactoring zu zahlen. Dies ist äußerst unwahrscheinlich, es sei denn, die Leistung oder die Funktionen wurden erheblich verbessert. Dann wird es auf den älteren Codebasen nicht passieren. Sie können es möglicherweise in das Budget für neuere Projekte einschleichen, wenn die Kunden über tiefe Taschen verfügen. Wenn Sie jedoch die APIs im Refactoring nicht ändern müssen, ist es für ältere Projekte nicht von Nutzen und führt möglicherweise ein Situation, in der das Unternehmen zwei Codebasen unterstützt, was weitere Kopfschmerzen und Kosten verursacht.

Als Ingenieur würde ich gerne den alten Code überarbeiten, der nicht mehr für den eigentlichen Zweck geeignet ist, jedes Mal, wenn etwas veraltet oder veraltet ist. Aber wie meine MDs in allen Unternehmen, in denen ich jemals gearbeitet habe, zu mir gesagt haben: "Wer wird bezahlen?"


12

Ich versuche immer aufzuräumen, während ich gehe. Ich bin nicht fertig, bis der Code sauber ist. Das Problem mit der technischen Verschuldung ist, dass die meisten Menschen es nicht verstehen. Der beste Weg, dies in Angriff zu nehmen, ist, nichts davon anzusammeln. Wenn Ihre Manager Ihren Entwicklern vertrauen, um zu entscheiden, wie ein Problem gelöst werden soll, können Sie die Codehygiene zu einem Teil jeder Programmieraufgabe machen. Wenn Sie nie einen schlechten Code einchecken, sammeln Sie keine Schulden an. Wenn Sie auch die Pfadfinder-Regel befolgen (lassen Sie den Code immer sauberer, als Sie ihn vorgefunden haben), werden Ihre bestehenden Schulden langsam verschwinden.

Ich sehe Refactoring nicht als eine Aufgabe, die von der Implementierung von Features getrennt ist. Es ist ein wesentlicher Bestandteil davon.


5
Ich könnte nicht mehr zustimmen: "Technische Schulden sind wie Finanzschulden - es ist auf lange Sicht viel einfacher, sie einfach nicht zu akkumulieren. Zahlen Sie alle Ihre technischen Rechnungen einmal pro Woche"
Lawrence Dol

7

Wenn Sie mit nicht-technischen Managern zu tun haben, ist es hilfreich, wenn Sie Ihre Diskussion in Begriffe umwandeln können, die sie verstehen. Wenn Sie einen realistischen Fall für einen positiven ROI der für die Tilgung der technischen Schulden aufgewendeten Arbeit aufstellen können, könnten Sie irgendwohin gelangen. Diese Übung hängt von Ihren Umständen ab, aber ein Beispiel könnte etwa so aussehen:

Analysieren Sie, wie viel Zeit Entwickler für die Unterstützung des Supports bei Produktionsproblemen aufwenden müssen, und stellen Sie dann fest, dass das Beheben von altem Code die Anzahl der Supportprobleme verringern würde C. Reduzieren Sie die Zeit, die die Entwicklung für Produktionsprobleme benötigt, wenn diese auftreten. Sagen wir es in Dollar, die gespart werden, wenn die Entwickler nicht mit Supportarbeiten beschäftigt sind. Weisen Sie auch darauf hin, dass jede Stunde, die ein Entwickler für Support ausgibt, ein "Doppelschlag" ist, da Sie nicht nur einen Entwickler für Support bezahlen, sondern auch die Opportunitätskosten für das verbrauchen, was dieser Entwickler tun könnte (Hinzufügen neuer Funktionen usw.) .)

Ja, einige der Zahlen werden Voodoo / Rauch und Spiegel sein ... das ist in Ordnung, das schmutzige Geheimnis des Managements ist, dass sie wissen, dass die Mehrheit der Zahlen, um die sie sich drehen, total BS sind, solange Sie ihnen etwas geben scheinbar konkret, damit sie es in den Kopf bekommen können, haben Sie eine Chance zu kämpfen.


6

Nach dieser Erklärung der technischen Schulden sollte Ihr Management davon überzeugt sein, sie zurückzuzahlen:

Stellen Sie sich vor, Sie haben eine sehr schmutzige Küche voller Müll. Bevor Sie eine Mahlzeit zubereiten, müssen Sie zunächst eine Stunde putzen. Und es ist jedes Mal so, wenn Sie essen wollen. Außerdem müssen Sie beim Zubereiten einer Mahlzeit besonders vorsichtig sein, um sicherzustellen, dass der Mist nicht in Ihre Mahlzeit fällt.

Die Küche ist Ihr Code, das Essen ist Ihr Produkt und das Essen verkauft Ihr Produkt.

Wenn sie es sich leisten können, ohne ein sicheres Netz von Komponententests länger auf die Implementierung einer Änderung zu warten, dann stimmt etwas in Ihrem Unternehmen nicht.


4

Es muss ein sehr überzeugendes Argument in Bezug auf das ursprüngliche Produkt und den Geschäftsfall sein, dass ich dieses Geld jetzt nicht verwenden kann, um etwas Wichtigeres für mich zu tun. Ob es Ihnen gefällt oder nicht, Ihr Management oder Ihre Kunden zahlen dafür und Sie müssen verkaufen können, um sie zu überzeugen.

Lassen Sie uns dies umformulieren, um sich als Kunde zu positionieren. Gutes altes Rollenspiel.

Angenommen, Sie haben einen Kühlschrank gekauft. Und Sie könnten einen Kühlschrank für 1000 US-Dollar kaufen, der von Acme Corp. einwandfrei funktioniert. Oder einen Kühlschrank für 2000 US-Dollar von Acme Deluxe Fridges, der äußerlich gleich aussah und die gleichen technischen Daten aufwies, aber geringere Wartungskosten aufgrund einer saubereren Innenarchitektur aufwies.

Was würden Sie als Kunde selbst kaufen?

Und was halten die Ingenieure von Acme Deluxe für die bessere Antwort?


3
Es fällt mir schwer, Ihre Haltung dazu zu bestimmen. Ich denke, Ihre Antwort ist "es kommt darauf an, was der Kunde will". Das Problem ist, dass nicht jeder Kunde versteht, dass der preisgünstigere Kühlschrank geschmolzenen, fiesen Müll aus dem Gefrierfach auslaufen wird, laute Geräusche macht und schließlich nach 5 Jahren seine Arbeit einstellt, während der andere 20 Jahre lang ruhig und leise läuft und nicht ersetzt werden, bis es von den Eigentümern als unmodern eingestuft wird, die es im Austausch gegen ein neues Modell weiterverkaufen. Trotzdem mag ich die Frage, die Sie gestellt haben. Es ist zum Nachdenken anregend. +1
jmort253

Erste Zeile - "Es muss ein sehr überzeugendes Argument sein, [] dass ich dieses Geld jetzt nicht verwenden konnte, um etwas Wichtigeres für mich zu tun." Ich benutze das Kühlschrank-Beispiel als ehrlich gesagt, es ist mir egal, was in meinem Kühlschrank vor sich geht. Ich will nur ein Ergebnis. (kaltes Essen zu einem vernünftigen Preis). Um ehrlich zu sein, es ist mir egal, ob die Kühlschrankingenieure es intern für ein besseres Produkt halten. Ich könnte sie konsultieren, aber es ist wirklich nicht ihre Entscheidung.
Jasonk

3

" Technische Schulden " können ein heikles Thema sein, um dem Management präsentiert zu werden, da sie die Notwendigkeit möglicherweise nicht erkennen. Die Frage könnte lauten, ob es in der Firma einen Champion gibt, der feststellt: "Schauen Sie, wir nehmen uns X% Zeit, um hier an der technischen Verschuldung zu arbeiten. Geben Sie uns 3 Monate, um Ihnen zu zeigen, dass dies gut funktioniert." ähnlich. Es gibt dort einen Anspruch auf Autonomie, aber auch einen Zeitrahmen, da sich das Management sonst fragen könnte, wie lange es dauert, bis es einige Ergebnisse sieht, was ein ziemlich gefährliches Gebiet darstellt.

Der erste Punkt ist jedoch, ob sie dies als Problem ansehen oder nicht. Wenn die sehbehinderte Person nichts über Brillen weiß und welche Art von Veränderungen sie bewirken kann, wie sollen sie dann verstehen, warum ein Sehtest wertvoll sein kann? Gleiche Idee hier, wo das Thema eher technisch und leider nicht leicht zu quantifizieren ist.


Dem stimme ich voll und ganz zu und finde es immer mehr. Vor kurzem habe ich eine Liste von Fehlern zusammengestellt, die wieder geöffnet wurden, weil keine ordnungsgemäße Lösung vorhanden war, oder von Fehlern ähnlicher Art. Hoffentlich haben die Entwickler Zeit investiert. Manchmal tun sie es, manchmal nicht, aber diese Art von Daten ist eine nützliche Grundlage, um dem Management zu zeigen, wie sich ein ungesundes Produkt auf ihr Geschäft auswirkt.
Desolate Planet

2
An meinem derzeitigen Arbeitsplatz werden Überstunden aus den falschen Gründen vergeben. Wenn Zeit investiert würde, um die App gesund zu halten, anstatt Probleme bei der Brandbekämpfung zu lösen, würde Geld für Überstunden gespart, und Entwickler würden mehr Befugnisse erhalten, als sie auszubrennen und sich über das Management zu ärgern.
Desolate Planet

Aber das Management (meistens richtig!) Sieht das so. Ich habe einen Magimix aus den 1980ern, der immer noch funktioniert, und du sagst mir, ich soll ihn ersetzen, nur weil er alt ist und die Farbe nicht mehr in Mode ist!
James Anderson

2

Sie sollten einfach aufhören, sich darüber zu beschweren.

Hier ist der Grund:

  1. Sie planen niemals, die Software länger als ein Jahr zu verwenden
  2. Es ist nur Zeitverschwendung, es zu optimieren, wenn sie danach planen, es zu löschen
  3. Es gibt einige echte Probleme, die jetzt behoben werden müssen
  4. Programmierer müssen nur lernen, mit Wartung umzugehen, auch wenn es nicht immer Spaß macht
  5. Sich zu beschweren, dass man besser weiß, was getan werden muss, ist arrogant - jemand anderes trifft die Entscheidung, und man sollte sich darüber freuen
  6. Sie vertrauen auf jeden Fall darauf, dass Sie guten Code schreiben

Der beste Weg ist also:

  1. Wenn sie Ihnen eine neue Aufgabe geben, versuchen Sie, diese in der vorgegebenen Zeit so gut wie möglich umzusetzen
  2. Schreiben Sie es perfekt beim ersten Mal. Wenn Sie es später ändern müssen, haben Sie beim ersten Mal einen Fehler gemacht und jede Änderung geht immer in die falsche Richtung - und es ist eine Lernmöglichkeit für Programmierer, wenn Sie Fehler machen.
  3. Bitten Sie nicht um zusätzliche Zeit, Sie werden es nicht bekommen, es gibt Fristen, die Sie kennen.

3
Ich stimme dem größtenteils zu, mit der Ausnahme, dass bekanntlich selbst beschissene Software dazu neigt, viel länger zu überleben, als die Entwickler erwarten. Aber du hast recht, es ist besser, sich nicht zu beschweren. Wenn Sie stattdessen ein Re-Factoring in begrenztem Umfang sehen, das die Verständlichkeit des Codes verbessert, lohnt es sich möglicherweise, die Änderungen OHNE ERLAUBNIS während Ihrer Wartung / Fehlerbehebungen vorzunehmen (und dabei ein Risiko einzugehen).
Angelo

@Angelo - Wäre es nicht besser, Ihre Bedenken zu äußern, als das Team in Ruhe leiden zu lassen? Ich habe gesehen, was dieses Problem für die Teammoral und auch für die Zeit- / Geldverschwendung bei Überstunden bedeutet. Ich sehe es nicht als "Stöhnen" an sich. Sie weisen lediglich auf Projektrisiken hin, und wenn Ihre Ideen Lieferzeiten verkürzen und Prozesse rationalisieren können, warum sollten Sie dann nicht zumindest versuchen, Ihre Bedenken auszudrücken? Wenn dies von tauben Ohren fällt, dann wissen Sie zumindest, wo Sie stehen.
Desolate Planet

2
Sie müssen sich lautstark darüber beschweren , sonst ist es Ihre Schuld, wenn der Code anderer Leute kaputt geht ("Sie wussten, dass dies ein Durcheinander ist und haben es niemandem erzählt?"). Aufstehen und loslegen "Hey Boss, diese Scheiße wird früher oder später den Fan treffen" ist entscheidend , um ein Entwicklerteam funktionsfähig zu halten.
Alex

1

Ich nehme an, Sie waren noch nie in ein Projekt involviert, um ein bestehendes System neu zu schreiben / zu ersetzen oder sogar zu aktualisieren.

Dies sind einige der schwierigsten Projekte, die erfolgreich abgeschlossen werden können. Einige der Probleme, denen Sie begegnen werden, sind:

  1. Geschäftsregeln gehen mit der Zeit verloren.
  2. Dokumentation und Implementierung stimmen nicht überein.
  3. Was Sie als Fehler sehen, sehen die Benutzer als Feature.
  4. Umgekehrt werden viele "Merkmale" von den Benutzern als Mängel angesehen.
  5. Sie werden keinen User-Buy-in erhalten - sie werden Ihre "Faktensuche" als "Nerds, die dumme Fragen stellen" ansehen, sie werden den Testaufwand als Zeitverschwendung ansehen, sie werden darauf bestehen, neue Funktionen hinzuzufügen, wodurch ein Projekt verlängert wird schon hinter dem Zeitplan sein.
  6. Möglicherweise stimmt der Quellcode nicht zu 100% mit der ausgeführten ausführbaren Datei überein.
  7. Während Ihre Abteilung an der Umgestaltung der Entwicklung herumspielt, wird das tatsächlich gewünschte Geschäft nicht abgewickelt.
  8. Es besteht die Möglichkeit, dass Ihr Re-Factoring "sauberere, verbesserte Schnittstellen" beinhaltet, wodurch andere Projekte in Ihren Sumpf aus verspäteten Lieferungen und fehlgeschlagenen Tests geraten.
  9. Nachdem das Projekt abgeschlossen wurde (weit über 50% dieser Bemühungen scheitern vollständig), haben Sie jegliche Glaubwürdigkeit verloren. Sie müssen in ein anderes Unternehmen in einer anderen Stadt umziehen, um jemanden zu finden, der bereit ist, Ihnen zuzuhören.
  10. Wenn das Projekt "erfolgreich" ist, wird sich jeder daran erinnern, was für ein Albtraum es war - Sie werden ...

Ich fordere Sie dringend auf, keine Re-Writes / Refactoring-Projekte wie die Pest zu vermeiden. Sie können einige der entmutigendsten Erfahrungen in einer professionellen Karriere sein.

Es steckt viel Weisheit in dem Satz "Wenn es nicht kaputt ist, repariere es nicht".


1
"Ich nehme an, Sie waren noch nie in ein Projekt involviert, um ein bestehendes System neu zu schreiben / zu ersetzen oder sogar zu aktualisieren" - Falsch, 7 Jahre davon.
Desolate Planet

1
Ich stimme voll und ganz zu, dass ein vollständiges Umschreiben oft eine Katastrophe ist. Aber ich habe drei Beispiele in den letzten 8 Jahren meiner Karriere. Eines war eine lange Panne, die dazu führte, dass wir das Produkt besser pflegen konnten, aber keinen geschäftlichen Nutzen erbrachten. Ein weiteres war eine kurze Umschreibung, die ein voller Erfolg war. Die dritte war die Entscheidung, nicht umzuschreiben, was letztendlich das Unternehmen tötete. Wähle dein Gift.
Tom Harrison Jr.

1

Für das Leben von mir kann ich nicht verstehen, warum manche Menschen so blind Angst vor Veränderungen haben - es schmeckt nach mangelndem Vertrauen in Ihre eigenen Fähigkeiten.

Ich habe letzte Nacht eine Show im Yosemite National Park gesehen und es wurde bemerkt, dass von 1940 bis Ende der 1990er Jahre kein einziger neuer Sequoia-Baum spross. Es wurde herausgefunden, dass der Grund dafür war, dass es strikte Richtlinien gegen das Verbrennen von Waldbränden gab und dass Sequoia-Tannenzapfen die Hitze des Feuers benötigten, um ihre Samen zu öffnen und freizusetzen.

Sie sehen, ein Feuer alle zehn Jahre oder so war gesund. Es räumte alles angesammelte Totholz und Brombeerholz ab, um die vorhandenen Bäume gesund zu erhalten (Prozesse) und Platz für neue zu schaffen (Features).

Ich bin gerade in einem Projekt, bei dem ein klarer Fall für eine Neuerstellung vorliegt: Die Legacy-Software wurde vollständig mit .NET-Webforms geschrieben. Fast die gesamte Geschäftslogik ist mit der HTML / Server-Tag-Ansichtslogik kombiniert und kann jetzt, da das Geschäft gewachsen ist, nicht auf andere Anwendungen ausgeweitet werden.

Das Management steht hinter der Aufgabe, weil sie ein angemessenes Maß an Vertrauen in ihre Entwickler haben, was, wie ich sehe, ein seltener Luxus ist.

Ja, fragen Sie sich, ob ein Umbau wirklich notwendig ist. Geben Sie Ihr Bestes, um vorhandenen Code wiederzuverwenden, der funktioniert, wo Sie können. Integrieren Sie diesen Code bei Bedarf in die Neuerstellung. Lassen Sie sich nur nicht davon überzeugen, dass es die einzige Möglichkeit ist, als Softwareentwickler zu existieren, wenn Sie Angst davor haben, mutige Änderungen vorzunehmen.

Viel Glück!


1
Wie beantwortet dies die Frage: "Wie teilen Sie dies dem Management mit, damit es Interesse daran hat, technische Schulden zu klären?"
gnat

1
@gnat: Wie beantworten die meisten "Antworten" diese Frage direkt? Siehe z. B. Antworten von James Anderson, tp1, oder Antworten oben mit den meisten Stimmen. Aber um Ihre Frage zu beantworten, stellte ich eine alternative Analogie zur Verfügung, die das OP verwenden kann. Mir scheint, dass Sie meiner Meinung in dieser Angelegenheit einfach nicht zustimmen. Das ist in Ordnung, aber kein Grund zur Ablehnung.
Matt Cashatt

1
Laut meiner Lesung scheint die beste Antwort, auf die Sie sich beziehen, die gestellte Antwort direkt zu adressieren, basierend auf den relevanten Erfahrungen. "Als ich mich mit meinem Chef getroffen habe, um dies zu besprechen ..." Ihrer Meinung nach stimme ich eher zu, aber ich stimme ab auf die inhaltliche Qualität, nicht darauf, ob ich eine bestimmte Meinung unterstütze oder nicht. Stack Exchange - Q & A Voting - Modell ist ziemlich schlecht , wenn (mis) für verwendete Meinungsumfragen
gnat

1
Ich empfehle es dann noch einmal zu lesen. Die Beschreibung eines Gesprächs mit seinem Vorgesetzten über eine Methode zur Deckung der technischen Schulden durch Auffüllen von Schätzungen für künftige Arbeiten beantwortet nicht die Frage: "Wie kommunizieren Sie dies dem Management, um es für die Klärung der technischen Schulden zu interessieren?" entweder. Trotzdem habe ich die Antwort nicht herabgestimmt, weil sie zur Unterhaltung beigetragen hat. Sie haben es also nur geschafft, eine Meinung zu der Angelegenheit zu unterdrücken, der Sie ohne wesentlichen Grund zustimmen. "Programmierer" sollten ein Ort sein, an dem wir uns unterhalten können. Nicht alles ist binär.
Matt Cashatt

1

Sie müssen Ihrem Management einen finanziellen Grund für den Umgang mit technischen Schulden und einen Rahmen für die Verwaltung des Abbaus dieser technischen Schulden geben.

Die Aufrechterhaltung eines technologischen Fahrplans ist ein solcher Rahmen. Wenn Sie mit einer Roadmap beginnen, können Sie nicht nur die technischen Schulden anhäufen, sondern auch die bestehenden Schulden reduzieren.

Viele erfolgreiche langfristige Projekte haben Lenkungsausschüsse und Roadmaps, die die Entwicklung leiten. Diese sind besonders hilfreich, wenn mehrere Entwicklungsteams und Interessengruppen beteiligt sind.

Mein Vorschlag ist, dass Sie diese Strategie mit Ihren Managern besprechen (und wenn möglich mit denen, die entscheiden, wo Geld ausgegeben wird).

Die allgemeine Vorgehensweise beim Erstellen und Verwalten einer Roadmap ist unkompliziert, erfordert jedoch die Unterstützung Ihres Managementteams. Definieren Sie zunächst ein Ziel. Definieren Sie die Elemente der technischen Verschuldung und entwickeln Sie eine Zielsystemarchitektur, die die Elemente Ihrer technischen Verschuldung reduziert. Denken Sie daran, es muss nicht perfekt sein, sondern nur funktionieren und besser als das, was Sie gerade sind. Berücksichtigen Sie Software, Entwicklungstools, Hardwareplattformen und wichtige neue Funktionen, die dem System hinzugefügt werden können. Führen Sie eine Kostenanalyse durch. Wenn Sie über die gewünschte Architektur verfügen, welche konkreten Vorteile bietet das Refactoring? (Zu den Vorteilen gehören kürzere Testzeiten, zuverlässigere Softwareprodukte, vorhersehbarere Entwicklungszyklen usw.) Wenn Sie genügend Vorteile für die Durchführung von Refactoring nachweisen können, erhalten Sie Unterstützung durch das Management.

Wenn Sie eine Roadmap und Managementunterstützung haben, entwickeln Sie eine Reihe von Schritten (auch Plan genannt), die Sie ausführen müssen, um in den gewünschten Zustand zu gelangen. Es kann eine gute Idee sein, einen Lenkungsausschuss zusammenzustellen, der die Roadmap verwaltet, die Entwicklungsteams auf der Roadmap schult und schult und Änderungen regelmäßig auf ihre architektonische Integrität überprüft.

Roadmaps sind wirklich nützlich, und vielleicht sollte die 13. Frage zum Joel-Test lauten: "Haben Sie eine Roadmap?"

Hier ist ein Video der ersten Stunde einer aktuellen Red Hat Linux-Roadmap-Sitzung .


1

Nachdem ich bereits an einer umfassenden Überarbeitung (nicht nur der Überarbeitung) beteiligt war, kann ich zustimmen, dass es eine der größten Hürden war, die Finanzleute dazu zu bringen, dem Projekt zuzustimmen. Um diese Hürde zu überwinden, musste ich einen Bericht verfassen, vorlegen und verteidigen, der auf eine Reihe von Problemen hinwies, die bedeuteten, dass das Geschäft des Unternehmens kurz- bis mittelfristig zum Erliegen kommen würde.

Schlüsselfaktoren für die Vereinbarung:

  • Vorhandener Code befand sich in einer nicht mehr unterstützten Toolkette (MicroPower Pascal), die nur auf einer nahezu nicht unterstützten Entwicklungsplattform (PDP11-23) ausgeführt werden konnte.
  • Es wurde fast unmöglich, Entwickler zu finden, die an Tools und Zielen arbeiten konnten.
  • Die Zielhardware war nicht mehr verfügbar, wenn Ersatzteile benötigt wurden und der Hersteller immer weniger bereit war, einen Reparaturservice bereitzustellen.
  • Probleme im Code führten zu leicht erkennbarer Unzufriedenheit der Kunden und direkten Wartungskosten.
  • Das Hinzufügen neuer Funktionen oder sogar von Fehlerkorrekturen wurde aufgrund von Einschränkungen der Zielhardware fast unmöglich, was dazu führte, dass andere Bereiche umgestaltet werden mussten, um Platz für die Behebung von Problemen zu schaffen.
  • Bei einer Bauzeit von 8 Stunden war das Entwickeln und Testen von Änderungen kostspielig.

In dem Bericht wurden die Probleme mit Schätzungen der laufenden Kosten detailliert beschrieben und drei Optionen angeboten:

  1. Frieren Sie ein, wo wir in naher Zukunft mit möglicherweise nicht einmal Fehlerkorrekturen waren.
  2. Optimieren Sie den Code nur für den Speicherplatz, ohne Rücksicht auf die Wartbarkeit, und weisen Sie darauf hin, dass jeder, der versucht, den optimierten Code zu warten, schlauer sein muss als jeder, der die Optimierung durchgeführt hat.
  3. Neuimplementierung mit Testbarkeit und Wartbarkeit als hohen Faktoren in einem branchenüblichen, allgemein gelehrten Sprachstandard (ANSI C) auf neuer, kostengünstiger COTS-Hardware (PC-104) mit mehreren verfügbaren Anbietern entworfene Schnittstellenkarte, damit sie mit der verbleibenden vorhandenen Hardware zusammenarbeiten kann. Hinzufügen eine begrenzte Anzahl von neuen Funktionen als Teil der Entwicklung, wie nicht-flüchtigen Speicher, ein Watchdog - Timer automatischen Neustart in einem Fehlerzustand zu schaffen , einige Einheiten mehrmals täglich abstürzt wurden und erfordert einen £ 40 Service - Aufruf, um zurückgesetzt , Bessere Diagnose im Prozess.

Nachdem ich den Startschuss für die 3. Option gegeben hatte, wurde mein 3-Monats-Vertrag zu 3 Jahren harter Arbeit, sowohl bei der Entwicklung der neuen Software als auch der Hardware, aber mit einem sehr guten Ergebnis.

Für Fälle mit weniger extremer technischer Verschuldung neige ich dazu, das anzunehmen, was ich Guerilla-Refactoring nenne:

Wenn es ein Problem mit einem bestimmten Modul gibt:

  1. Schreiben Sie eine Reihe von Tests, die das Problem aufzeigen, das wahrscheinlich auch ohne Refactoring fehlschlägt
  2. Refactor als Teil der Entwicklung, der darauf hinweist, dass die Tests immer noch fehlschlagen.
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.