it-swarm-eu.dev

Wie kann ich das Management davon überzeugen, mit technischen Schulden umzugehen?

Diese Frage stelle ich mir oft, wenn ich mit Entwicklern zusammenarbeite. Ich habe bisher in vier Unternehmen gearbeitet und bin mir bewusst geworden, dass es nicht darauf ankommt, den Code sauber zu halten und mit technischen Schulden umzugehen, die den zukünftigen Fortschritt in einer Software-App behindern. Zum Beispiel hatte das erste Unternehmen, für das ich gearbeitet habe, eine Datenbank von Grund auf neu geschrieben, anstatt etwas wie MySQL zu verwenden, und das hat dem Team beim Umgestalten oder Erweitern der Anwendung die Hölle bereitet. 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 vorhanden ist, und es ist schrecklich zu sehen, welche Auswirkungen dies auf die Moral des Teams hat.

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 verschlechtern. Wie teilen Sie dies dem Management mit, um es für das Aussortieren von technischen Schulden zu interessieren?

164
Desolate Planet

Als ich mich mit meinem Chef traf, um dies zu besprechen, sagte er, ich sollte Refactoring in alle meine Schätzungen einbeziehen. Er sagte, es sei kein Problem, ü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 all 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 gewinnen und schneller Marktanteile gegenüber Ihren Mitbewerbern zu gewinnen. Wie Kredit, wenn es richtig verwaltet wird, kann es Sie ziemlich erfolgreich machen.

194
jmort253

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 dafür, dass die Antwort wirklich "Nein" ist. Leider glaube ich nicht, dass das, was Sie versuchen, getan werden kann. Es ist nicht so, dass ich versuche, pessimistisch zu sein, sondern ich versuche ehrlich zu sein.

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

Ich denke, ich mag, was Renesis in seiner Antwort gesagt hat, weil es eines der wenigen ist, das versteht, dass das Management ganz anders denkt als das Engineering. Und ich denke, wir haben alle gesehen, wie sich Unternehmen zu einem datumsorientierten und projektgesteuerten Unternehmen entwickelt haben, anstatt sich auf Kunden und Qualität zu konzentrieren. Damit meine ich typische Unternehmen, nicht die wirklich starken, die den Mut haben zu sagen "Es wird getan, wenn es getan ist" (wie Apple Computer oder ID-Software - und ja, ich verstehen, dass es Menschen manchmal nicht frei steht, diesen Ansatz zu wählen).

Aber hier ist die Sache: Unternehmen, die den Ansatz der Qualität an erster Stelle verfolgen ... was fällt Ihnen an ihnen auf? Das stimmt, sie werden von Ingenieuren geführt, nicht von Verkäufern, Vermarktern, Projektmanagern oder Buchhaltern. Denken Sie an HP, Apple, ID, Google, Microsoft und IBM. Alles begann und wurde von Ingenieuren und nicht von Verkäufern erfolgreich gemacht, obwohl Verkäufer sicherlich eine Rolle spielten, und ich bin sicher, dass viele darüber diskutieren würden, Microsoft mit Qualität in Verbindung zu bringen :). Und von denen haben sich diejenigen, die bergab gingen, von der technischen Führung gelöst. Diese Aussage enthält jedoch eine ganze Reihe von Argumenten, da es viele technische Unternehmen gibt, die letztendlich gescheitert sind, weil sie sich nicht an veränderte Zeiten anpassen und ihr eigenes Wachstum steuern können. Ich sehe in der technischen Führung keine Ursache für diese Fehler. Für mich ist dies ein Problem der Fähigkeiten und des Geschäftssinns, die unabhängig davon sind, ob jemand Entwickler oder Buchhalter ist. Generell denke ich jedoch, dass das Engineering den strengen Anforderungen der Rechenschaftspflicht und Disziplin verpflichtet ist, von denen Unternehmen profitieren, bei denen das Engineering eine Komponente darstellt.

Im Ernst, schau dich um. IT-Führung fehlt schmerzlich. Der Fokus liegt immer auf Kosten und Zeit und selten auf Qualität, solange es gut genug ist. IT-Verantwortliche berichten selten mehr an den CEO, jetzt ist es immer der CFO. Die IT steckt in der Produktionsunterstützung fest und ist zunehmend den Projektmanagern verpflichtet, deren Fokus auf kleineren, besser verdaulichen und messbaren Teilen liegt, nicht auf signifikanten Ä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).

Es tut mir leid, dass Sie diesen Beitrag so lange brauchen, aber am Ende denke ich, dass Ihre Frage, wie das Management sich um technische Schulden kümmert, oft besser gelöst wird, indem Sie den richtigen Leiter finden, anstatt den bestehenden zu ändern. Die technische Verschuldung Standarddenkern zu erklären bedeutet, den Fokus auf Geld und Kosten zu verlagern, wie Renesis sagte, und ich denke, dass dies bei der Übersetzung viel verliert. Selbst wenn Sie erfolgreich wären, wäre es nur wichtig, wenn der Top-Leader des Unternehmens es gekauft hätte. Wenn Sie Ihren mittleren Manager davon überzeugen, das Richtige zu tun, wird er wahrscheinlich nur entlassen.

48
Bernard Dy

Das erste, was zu tun ist, ist den Wortlaut zu ändern. Wenn man es "technische Schulden" nennt, kommt das Management auf die Idee, dass es eine Investition ist - wenn es wirklich so ist eher wie ein Virus. (Ich bin wie der Dave Ramsey der technischen Schulden.)

Das Erlauben, dass es unbezahlt bleibt, ist mit enormen Kosten verbunden, die nicht gesehen oder leicht quantifiziert werden können.

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

  • Die Schätzungen für neue Funktionen sind viel höher als nötig. Oder überhaupt unmöglich.
  • Schlechter Code erzeugt mehr schlechten Code
  • Die Fehlerliste wächst auch dann, wenn Entwickler sie ständig beheben
  • Teammitglieder gehen (dies selbst kann zeigen, dass es ein Problem gibt, wie in diese ausgezeichnete Antwort erklärt)
43
Nicole

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

Eine Möglichkeit, den Druck aufrechtzuerhalten, besteht darin, immer dann, wenn ich nach einem Kostenvoranschlag gefragt werde, Zeit zu sparen, wenn ich mich nicht mit bestimmten technischen Schuldenproblemen befassen müsste, das beziehe ich in meinen Kostenvoranschlag ein. Zum Beispiel " Ich brauche 2-3 Tage, um diesen Fehler aufzuspüren, aber wenn wir diese beiden anderen Fehler mit niedriger Priorität, die sich schon immer in der Warteschlange befanden, bereits behoben hätten, wäre dies der Fall Nehmen Sie wahrscheinlich weniger als eine. "Oft besteht die Antwort darin, die anderen zu reparieren, während Sie gerade dabei sind.

Ich stimme auch anderen Antworten zu, in denen es darum geht, Verbesserungen als Teil Ihres Jobs zu betrachten und sie im Laufe der Zeit zu erledigen, wenn sie nicht zu störend sind. Meine aktuelle Aufgabe besteht darin, sehr schlecht gestalteten Code zu ergänzen. Anstatt das Chaos zu vergrößern, indem ich meinen neuen Code passend schreibe, verbringe ich ein wenig Zeit im Voraus damit, die allgemeinen Funktionen zu konsolidieren, sodass das Senden eines Pakets zu einem einzeiligen Funktionsaufruf wird, anstatt ständig 15 Zeilen leicht modifizierter Kopien zu wiederholen. Kesselplatte einfügen.

Ich weiß, dass es die Gesundheit einiger Betreuer weiter unten retten wird. Ich weiß, weil ich heute dieser Betreuer bin. Ich glaube jedoch auch, dass dies meine derzeitige Aufgabe beschleunigen wird, diese Funktion jetzt einzuführen und zu debuggen.

Eine andere Technik, die ich in der Vergangenheit verwendet habe und die ich noch einmal anwenden sollte, ist einen Refactoring-DVCS-Zweig in einem separaten Arbeitsbaum behalten für diese Ausfallzeit, wenn Sie kompilieren, auf einen langen Test warten oder Benötigen Sie nur eine kurze Abwechslung, wenn Sie wegen eines Fehlers ausgebrannt sind. Solange Sie gelegentlich vom Upstream zusammengeführt werden, damit Sie nicht zu weit auseinander gehen, können Sie mit sehr geringem Aufwand so lange dauern, wie Sie Änderungen vornehmen möchten. 15 Minuten hier und da pro Tag können sich im Laufe der Zeit wirklich summieren.

30
Karl Bielefeldt

Sie könnten die Kreditkartenanalogie versuchen. 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 von uns Entwicklern verwendeten Fachbegriffe. 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, den Ernst des Problems in Bezug auf Software-Entropie zu erkennen.

Aber wenn dies sie nicht überzeugt, versuchen Sie, sachliche Beweise zu sammeln und einige Berechnungen durchzuführen. Z.B. Wie viel kostet es für das Unternehmen - sowohl in bar als auch in verlorener Zeit -, einen ausscheidenden Mitarbeiter zu ersetzen?.

20
Péter Török

Niemand wird Geld geben, um etwas, das funktioniert, durch etwas anderes zu ersetzen, das (mit etwas Glück) auch funktioniert.

Was Sie tun können, ist vorzuschlagen, es durch etwas zu ersetzen, das mehr bewirkt, d. H. Die Bedienung von technologischen Schulden zu 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, ein neues Projekt "einzuschleusen".

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 erstellen 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 Code-Qualitätsstandard einführen, werden Ihre neun bis fünf Entwickler einen Weg finden, das System zu bedienen, während Ihre engagierten Entwickler sich unweigerlich über das gesamte Verfahren ärgern werden (was nicht der Fall ist) Ich habe nicht gesagt, 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 dem Fortfahren und dem Aufräumen der dort vorhandenen Produkte.

12
biziclop

Tatsache ist, dass in vielen Unternehmen, insbesondere angesichts der aktuellen wirtschaftlichen Situation, jede Stunde jemandem in Rechnung gestellt werden muss.

Oder sie gehen runter, schnell.

Es sei denn, die bestehenden Kunden sind bereit, für das Refactoring zu zahlen, was zutiefst unwahrscheinlich ist, es sei denn, es bietet eine erheblich verbesserte Leistung oder Funktionen. 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 Clients tiefe Taschen haben, aber wenn Sie 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 alten Code überarbeiten, der nicht mehr wirklich zweckmäßig ist, jedes Mal, wenn etwas veraltet oder veraltet ist. Aber wie meine Geschäftsführer in allen Unternehmen, in denen ich jemals gearbeitet habe, zu mir gesagt haben: "Wer zahlt?"

12
Orbling

Ich versuche immer aufzuräumen, wenn ich gehe. Ich bin erst fertig, wenn der Code sauber ist. Das Problem mit technischen Schulden ist, dass die meisten Leute es nicht verstehen. Der beste Weg, dies in Angriff zu nehmen, besteht darin, nichts davon anzusammeln. Wenn Ihre Manager darauf vertrauen, dass Ihre Entwickler entscheiden, wie ein Problem gelöst werden soll, können Sie Code-Hygiene zu einem Teil jeder Programmieraufgabe machen. Wenn Sie niemals schlechten Code einchecken, akkumulieren Sie keine Schulden. Wenn Sie auch die Pfadfinder-Regel befolgen (lassen Sie den Code immer sauberer als Sie ihn vorgefunden haben), verschwinden Ihre bestehenden Schulden langsam.

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

12
EricSchaefer

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 zur Tilgung der technischen Schulden aufgewendeten Arbeit erstellen 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 A. die Anzahl der Supportprobleme verringern würde, B. es dem Support erleichtern würde, Probleme zu lösen, ohne zur Entwicklung zu eskalieren, und C. Reduzieren Sie die Zeit, die die Entwicklung für Produktionsprobleme benötigt, wenn diese auftreten. Sagen wir es in Dollar gespart, wenn Entwickler nicht an Support-Arbeiten gebunden sind. Weisen Sie auch darauf hin, dass jede Stunde, die ein Entwickler mit Support verbringt, ein "Doppelschlag" ist, da Sie nicht nur einen Entwickler für Support bezahlen, sondern auch die Opportunitätskosten für das verbrennen, 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, die sie herumschleudern, total B.S. Solange du ihnen etwas scheinbar Konkretes gibst, mit dem sie arbeiten können, damit sie es in ihren Kopf bekommen, hast du eine Chance zu kämpfen.

7
mindcrime

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 Mist. Bevor Sie eine Mahlzeit zubereiten, müssen Sie zunächst eine Stunde lang putzen. Und das ist jedes Mal so, wenn Sie essen wollen. Auch bei der Zubereitung einer Mahlzeit müssen Sie 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, länger auf die Implementierung einer Änderung zu warten, ohne ein sicheres Netz von Komponententests zu haben, stimmt etwas in Ihrem Unternehmen nicht.

6
BЈовић

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 konnte, um mir etwas Wichtigeres anzutun. 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 bei Acme Corp. einwandfrei funktioniert, oder einen Kühlschrank für 2000 US-Dollar bei Acme Deluxe Fridges, der äußerlich gleich aussah und die gleichen technischen Daten aufwies, aber aufgrund einer saubereren internen Architektur geringere Wartungskosten aufwies.

Was würden Sie als Kunde selbst kaufen?

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

4
jasonk

" Technische Schulden " kann ein schwieriges Thema sein, das dem Management vorgelegt werden muss, da es möglicherweise nicht die Notwendigkeit dafür sieht. Die Frage könnte lauten: "Schauen Sie, wir nehmen uns X% Zeit, um 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 ist.

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

3
JB King

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

Hier ist der Grund:

  1. Sie planen nie, die Software länger als ein Jahr zu verwenden
  2. es ist nur Zeitverschwendung, es zu optimieren, wenn sie es später entsorgen wollen
  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 Sie besser wissen, was zu tun ist, ist arrogant - jemand anderes trifft die Entscheidung, und Sie sollten sich darüber freuen
  6. Sie vertrauen dir sowieso, dass du guten Code schreibst

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 beim ersten Mal perfekt. 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 dafür, Sie werden es nicht bekommen, es gibt Fristen, die Sie kennen.
2
tp1

Ich gehe davon aus, dass Sie noch nie an einem Projekt beteiligt waren, um ein vorhandenes 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, auf die Sie stoßen werden, sind:

  1. Geschäftsregeln gehen mit der Zeit verloren.
  2. Dokumentation und Implementierung sind völlig nicht synchron.
  3. Was Sie als Fehler sehen, sehen die Benutzer als Feature.
  4. Umgekehrt werden viele "Funktionen" von den Benutzern als Fehler angesehen.
  5. Sie werden kein User-Buy-In erhalten - sie werden Ihre "Tatsachenermittlung" als "Nerds, die dumme Fragen stellen" betrachten, sie werden den Testaufwand als Zeitverschwendung betrachten, 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 laufenden ausführbaren Datei überein.
  7. Während Ihre Abteilung an der Umgestaltung der Entwicklung herumspielt, wird das tatsächlich gewünschte Geschäft nicht durchgeführt.
  8. Es besteht die Möglichkeit, dass Ihr Re-Factoring "sauberere, verbesserte Schnittstellen" beinhaltet, wodurch andere Projekte in Ihren Sumpf verspäteter Lieferung und fehlgeschlagener Tests geraten.
  9. Nachdem das Projekt eingestellt wurde (weit über 50% dieser Bemühungen scheitern vollständig), haben Sie jegliche Glaubwürdigkeit verloren - Sie müssen zu einem anderen Unternehmen in einer anderen Stadt ziehen, um jemanden zu finden, der bereit ist, Ihnen auch 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, Umschreibungen/Refactoring-Projekte wie die Pest zu vermeiden. Sie können zu den entmutigendsten Erfahrungen in jeder professionellen Karriere gehören.

Es gibt viel Weisheit in der Phrase "Wenn es nicht kaputt ist, reparieren Sie es nicht".

2
James Anderson

Nachdem ich bereits an einer umfassenden Umschreibung beteiligt war (nicht nur an einem Refactor), 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 schreiben, präsentieren und verteidigen, der auf eine Reihe von Problemen hinwies, die dazu führten, dass das Geschäft des Unternehmens kurz- bis mittelfristig tot im Wasser sein würde.

Schlüsselfaktoren für die Umsetzung der Vereinbarung:

  • Vorhandener Code befand sich in einer nicht mehr unterstützten Toolkette (MicroPower Pascal), die nur auf einer nahezu nicht unterstützbaren Entwicklungsplattform (PDP11-23) ausgeführt wurde.
  • 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 und der Hersteller zögerten immer mehr, einen Reparaturservice anzubieten.
  • Probleme im Code führten zu leicht erkennbarer Unzufriedenheit der Kunden und direkten Wartungskosten.
  • Das Hinzufügen neuer Funktionen oder sogar Fehlerkorrekturen wurde aufgrund von Einschränkungen der Zielhardware fast unmöglich, was dazu führte, dass andere Bereiche umgestaltet werden mussten, um Platz bei der Behebung von Problemen zu schaffen.
  • Mit 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. Einfrieren, wo wir waren, mit möglicherweise nicht einmal Bugfixes in naher Zukunft.
  2. Optimieren Sie den Code nur für den Speicherplatz, ohne Rücksicht auf die Wartbarkeit, nd weisen Sie darauf hin, dass jeder, der versucht, den optimierten Code zu warten, schlauer sein muss als derjenige, der die Optimierung durchgeführt hat.
  3. Implementieren Sie mit Testbarkeit und Wartbarkeit als hohen Faktoren in einer branchenüblichen, weit verbreiteten Sprache (ANSI C) auf neuer, kostengünstiger COTS-Hardware (PC-104) neu, wobei mehrere Anbieter mit einem internen Anbieter verfügbar sind Entwickelte Schnittstellenkarte, damit sie mit der verbleibenden vorhandenen Hardware arbeiten kann. Hinzufügen eines begrenzten Satzes neuer Funktionen als Teil der Entwicklung, wie z. B. nichtflüchtiger Speicher, ein Watchdog-Timer, der im Fehlerfall einen automatischen Neustart ermöglicht einige Geräte stürzten mehrmals am Tag ab und erforderten einen Serviceabruf von 40 GBP out to reset, bessere Diagnose im Prozess.

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

In Fällen mit weniger extremen technischen Schulden tendiere ich dazu, das zu übernehmen, was ich Guerilla-Refactoring nenne:

Wenn es ein Problem mit einem bestimmten Modul gibt:

  1. Schreiben Sie eine Reihe von Tests, die das Problem demonstrieren die wahrscheinlich auch ohne Refactoring fehlschlagen
  2. Refactor als Teil der Entwicklung weist darauf hin, dass die Tests immer noch fehlschlagen.
2
Steve Barnes

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

Ich habe gestern Abend eine Show im Yosemite-Nationalpark gesehen und es wurde bemerkt, dass von 1940 bis Ende der 90er Jahre kein einziger neuer Sequoia-Baum spross. Es wurde festgestellt, dass der Grund dafür war, dass es eine strikte Politik gegen das Verbrennen von Waldbränden gab und dass Sequoia-Tannenzapfen die Hitze des Feuers brauchten, um ihre Samen zu öffnen und freizusetzen.

Sie sehen, ein Feuer alle zehn Jahre war gesund. Es räumte das gesamte angesammelte Totholz und die Brombeere aus, um die vorhandenen Bäume (Prozesse) gesund zu halten und Platz für neue (Merkmale) zu schaffen.

Ich bin gerade in einem Projekt, das einen klaren Grund für eine Neuerstellung hat: Die Legacy-Software wurde vollständig mit .NET-Webformularen geschrieben. Fast die gesamte Geschäftslogik wird mit der HTML/Server-Tag-Ansichtslogik vermischt und kann nach dem Wachstum des Geschäfts nicht mehr auf andere Anwendungen erweitert werden.

Das Management steht hinter der Aufgabe, weil sie ein angemessenes Maß an Vertrauen in ihre Entwickler haben, was meines Erachtens 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 die Angst vor mutigen Änderungen der einzige Weg ist, als Softwareentwickler zu existieren.

Viel Glück!

1
Matt Cashatt

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 einer technologischen Roadmap ist ein solcher Rahmen. Wenn Sie mit einer Roadmap beginnen, können Sie sich nicht mit technischen Schulden anhäufen und bestehende Schulden reduzieren.

Viele erfolgreiche langfristige Projekte haben Lenkungsausschüsse und Roadmaps als Leitfaden für die Entwicklung. Diese sind besonders hilfreich, wenn mehrere Entwicklungsteams und Stakeholder beteiligt sind.

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

Der allgemeine Ansatz zum 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 Elemente Ihrer technischen Verschuldung reduziert. Denken Sie daran, es muss nicht perfekt sein, nur funktionsfähig und besser als das, was Sie derzeit 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 die gewünschte Architektur haben, welche konkreten Vorteile bietet das Refactoring? (Zu den Vorteilen gehören eine kürzere Testzeit, zuverlässigere Softwareprodukte, vorhersehbarere Entwicklungszyklen usw.) Wenn Sie genügend Vorteile für die Durchführung von Refactoring nachweisen können, erhalten Sie Managementunterstützung.

Sobald Sie eine Roadmap und Managementunterstützung haben, entwickeln Sie eine Reihe von Schritten (auch als Plan bezeichnet), die Sie ausführen müssen, um diesen gewünschten Zustand zu erreichen. 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 beim Joel-Test lauten: "Haben Sie eine Roadmap?"

Hier ist ein Video der ersten Stunde einer kürzlichen Red Hat Linux-Roadmap-Sitzung .

1
Jay Elston