Refactoring - wenn Deine Software bald stirbt... 

Hi David, es geht aus meiner Sicht nicht um das Thema Prinzip oder Bequemlichkeit, sondern um Kosten-Nutzen für den Kunden. Das Problem sitzt dann meist vor dem Rechner und will es unbedingt hochwertig machen. Der Kunde hingegen will häufig die Kuh hungern lassen und dann noch melken, bis sie stirbt.

Hi David! Cooles Thema. In einer ähnlichen Situation war ich schonmal, allerdings war das meine erste Stelle und ich war noch unerfahren und de facto alleiniger Entwickler mit externer Unterstützung. Es war ebenfalls spezielle Software mit nur noch wenigen anderen Nutzern weltweit. Ich habe damals vermieden irgendwelchen legacy Code anzupassen und mein eigenes Mini-Framework neben die eigentliche Software geschrieben, diese hat als Art Fassade für die Eigentliche Software gewirkt. In diesem konnten ich und nun auch Externe, ohne Wochenlanges einlesen, Erweiterungen der Funktionalität durchführen ohne sich noch viel mit dem legacy Code auseinandersetzen zu müssen. Es musste nur noch an einigen Stellen an das alte System angebunden werden; so konnte allerdings der neue Code weitgehend ohne Kenntnisse des alten Spaghetti Codes entwickelt werden. Die neu entwickelten Teile können potenziell auch später noch umgezogen werden, da nur das Mini-Framework als Adapter ausgetauscht werden müsste. Bloß bei kleinen Veränderungen in vorhandener Funktionalität wird es schwierig zu entscheiden. Da gibt es dann allerdings drei anstatt zwei Möglichkeiten: Minimale Anpassung, Refactoring (mit variablem Aufwand), Funktionalität komplett Ersetzen (mit Hilfe des Frameworks). Ich habe mich allerdings nie für das Refactoring entschieden. PS Es gab auch keine Tests für den legacy Code; womit ich Refactoring unzumutbar finde.

Interessant, wir haben ein ähnliches Thema mit einem Kernkraftwerk in Bayern. Allerdings beantwortet bei uns die Frage der Auftraggeber, der die Änderungen bezahlen muss. Wenn die Änderungen zu teuer sind, gibt es das Refactoring nicht. Persönlich würde ich das Refactoring machen, um am Ende ein vernünftiges Stück Software zu haben. Und um zu zeigen das es geht und weil mir meine Arbeit spass macht. Dabei kann man sicher auch eine Menge lernen und für weitere Projekte/Arbeitgeber nutzen.

Wenn man sieht wie lange so ein Atomkraftwerk zurückgebaut wird, spricht man hier warscheinlich eher über 10 Jahre Plus. D.h. man würde sich ja die nächsten 10 Jahre mit der Software rumquälen um etwas zu aktualisieren. Da hätte ich als Entwickler schon keine Lust drauf und ich finde 10 Jahre oder mehr ist schon eine Richtig lange Zeit für eine Software. Ich würde mir die Zeit nehmen die Software soweit zu refactoren das man zumindest anpassungen einfacher vornehmen kann und das Änderungen sicherrer durchgeführt werden können und nur bei Bedarf an den jeweiligen Stellen auch noch z.B. für Modularität vorsorgen. Aber der Arbeitsalltag sollte so gestaltet werden das es kein Kampf ist die Software anzupassen.

Ich kann verstehen, dass dir das den Schlaf raubt. Keine leichte Entscheidung. Natürlich hat man als Entwickler auch so eine gewisse Eitelkeit und will seinen Code immer optimal haben. Andererseits sucht man natürlich auch immer nach neuen Herausforderungen. An einem Produkt zu arbeiten, dessen Lebensende nah ist, ist vermutlich nicht sehr spannend. Ich habe gelernt, dass man auch loslassen muss. Selbst habe ich auch über ein Jahrzehnt ein Projekt geführt und als ich die Firma verlassen habe, ging das in neue Hände. Oder sie haben das Produkt eingestampft. Das weiß man nie. Irgendwann habe ich für mich beschlossen, dass es mir egal ist. Obwohl ich sehr viel Herzblut darein gesteckt habe, war es nie mein Produkt. Auch wenn ich das gerne behauptet habe. Ich wurde bezahlt um einen Job zu tun. Am Ende stellt sich vielleicht die Frage, wer bereit ist, das zu bezahlen. Wenn das Finanzielle geklärt ist, dann gib dein Bestes, wie du es vermutlich immer tun würdest. Was auch immer du mit dem Projekt anstellst, vermutlich kannst du dabei etwas lernen und wirst zumindest nicht dümmer als zuvor. Selbst wenn das Projekt irgendwann stirbt, kannst du die Erfahrung daran mitnehmen.

"Wie lange soll die Software leben?" ist generell eine wichtige Frage (auch bei Greenfield-Projekten). In den wenigsten Fällen bekommt man vom Kunden "ein paar Monate", in den meisten Fällen "Ewig, sprich 10 Jahre ++" zurück. Je länger sie halten soll um so leichter lässt sich Qualität verkaufen. In diesem konkreten Fall lässt sich das wahrscheinlich sehr leicht bestimmen, der Rückbau ist zeitlich terminiert, wie es nachher weiter geht und wie lange wird man auch großteils wissen. Es stellt sich auch die Frage ob man in diesem Fall die neuen Funktionalitäten nicht in einem eigenem Projekt abwickeln kann und evtl. die alte Datenbasis mitbenutzen kann. Kommt die Anforderung "Wir müssen an der Qualität arbeiten" von den Entwicklern oder vom Management? Kennt das Management das Problem? Wenn nicht muss hier das Gespräch gesucht werden. Eigene Qualitätsansprüche würde ich eher unterordnen, letztlich muss das Management entscheiden wie viel Energie investiert wird.

Hallo David, ich verstehe total den Aspekt des Anspruches auf eine "saubere" Software. Programmieren ist (fast) immer auch eine Leidenschaft. Mir geht es da ganz genau so. Ich denke, die Frage ist deshalb so schwierig zu beantworten, weil es meiner Meinung nach darauf keine allgemeine Antwort gibt. Was heißt z.B. "bald"? Wochen, Monate, Jahre? In dem Fall des Kernkraftwerkes sind es wahrscheinlich noch Jahre; eine Bereinigung hätte somit wohl auch noch die gewünschten Effekte; bei einer Software die nur noch ein paar Monate lebt, sieht das schon ganz anders aus. Oder die Frage, ob Teile der Software vielleicht in einem anderen Projekt wiederverwendet werden können. Letztendlich kommt es daher meiner Meinung nach auf den konkreten Fall an. Das Ziel sollte sein, eine gute Balance zu finden zwischen der "Sauberkeit" einer Software und deren Wirtschaftlichkeit.

Ich würde nur das nötigste refactoren, insbesondere Teile die häufig oder sehr wahrscheinlich noch einmal verwendet oder erweitert werden. Hier sehe ich schon den wirtschaftlichen Aspekt. Immer mit der Frage: Was bringt einem das Refactoring und welches Refactoring bringt einem am meisten. Also z.B. so viel refactoren wie auch daran entwickelt wird und dabei ist Priorisierung sehr wichtig, genauso wie bei der Softwareentwicklung im Allgemeinen. Nützlich ist auch die Boy Scout Rule, d.h. on the fly kleinere Dinge refactoren.

Software lebt in den seltensten Fällen ewig. In deinem Fall kennen wir lediglich das Datum. Es hat sich "eigentlich" nichts verändert. Die einzige Änderung ist, dass wir die vertretbaren Refactoring-Änderungen besser einschätzen können. Und im Falle des Atomkraftwerks können wir sogar die Bereiche identifizieren und gewichten, die überarbeitet werden. Bei deutschen funktionieren Auto-Analogien immer super. Meine wäre hier: Deine Karre hat 200k aufm Tacho, nen paar Dellen und ist generell nicht das geilste Modell, aber bringt dich von A nach B. Du weißt "ich fahr die Möhre bis die Schrott ist - hat keinen Wiederverkaufswert, danach hol ich mir ne neue". Du würdest wahrscheinlich zusehen, dass die Karre regelmäßig durchgecheckt wird (Bremsen, Flüssigkeiten etc). Aber zum Lackierer fahren um die Kratzer auszubessern oder das Teil ausbeulen lassen? Eher weniger.

Es kommt drauf an. Im großen und ganzen würde ich nicht viel Energie mehr rein stecken. Wenn ich allerdings weiß, das ich immer und immer wieder mit bestimmten Fällen zu tun haben werde, würde ich diese bearbeiten um hier so wenig Probleme zu haben wie möglich. Ich habe auch ein Herzensprojekt, vielleicht sogar zwei, aber eines davon habe ich nach Jahren archiviert. Ich kann es mir immer ansehen, als Stück meiner Entwicklergeschichte, aber ich mache nichts mehr daran. Ich konzentriere mich auf neues.

Team "Prinzipien". Begründung: Ich stecke maximal in einem Refactoring meines organisch gewachsenen Produktes und muss/will Versäumnisse aus mindestens einer Dekade bzw. technische Schulden tilgen. Der Maßnahmenkatalog geht aber so weit, dass nicht absehbare Folgeversionen enormen Vorteil von angedachten und auch bereits implementierten Erweiterungen (ja, korrekt - Neuentwicklung gänzlich weiterer Ideen) hätte. Ob die Rechnung später auf geht? Das weiß ich nicht. Ich stecke nun sehr viel Herz, Hirn und Zeit dort hinein. Also eigentlich so, wie ich das in diesem (Hobby-)Produkt seit 2005 bereits mache. "Hinrotzen", "Hauptsache läuft" oder Vergleichbares kommt mir nicht (mehr) in den Source. Ich würde also, auch mit Blick auf eine wissentliche Abschaltung, dennoch meinen Prinzipien weiterhin treu bleiben. Danke für dieses Video, Herr Tielke.

It depends 😉 Ich finde es kommt immer auf die Wirtschaftlichkeit an (Auch bei Produkten die länger leben). Muss es immer die goldene Lösung sein? Ich finde in der Regel die pragmatische Lösung, welche trotzdem „gut“ wartbar ist am besten. Bei einem Atomkraftwerk spielt natürlich die Sicherheit die Hauptrolle, da ist dann das Wirtschaftliche mehr im Hintergrund. Das gleiche Thema wie mit der Codeabdeckung bei UnitTests (Kann ich mir >95% leisten? Reichen 80%?)

Ich würde nur die nötigen Refactorings machen um die Software weiterbetreiben zu können. Heisst, wenn ich einen Mask/Screen/Logik ändern muss, dieses soweit "verbessern", dass man keine Neuerfindung draus macht, aber zumindest den Code dadurch lesbarer und etwas ausgeräumter hat. Aus dem ein oder anderen Kundenprojek von mir kenne ich die Situation sehr gut, ab wann man mit dem Refactoring anfängt und ab wann ist es quasi zu viel. Bisher hat es sich immer gezeigt, dass so "kleine Refacotrings" wenn man in diesem Codebereich sowieso anfassen muss, die meiste Wirkung erzielt hat und somit effektivier waren als wenn gefühlte 10 Scrum-Sprint nur für reines Refactoring genutzt wurden.

Hi David ich stehe mehr oder weniger auch gerade vor einem ähnlichen (Eigentlich noch traurigerem) Dilemma. Wir haben für einen Kunden ein Frontend gebaut. Ursprünglich war es mit extrem hoher Komplexität und Dynamik geplant, was wir dann initial auch bedacht und aufgebaut hatten, aber wurde mit der Zeit dann gestrichen, weil zu teuer. Die Basis für diese Dynamik steht aber - und macht den Code ziemlich komplex und schwieriger Wartbar. (Background: Der Kunde wollte später in der Lage sein anhand einer JSON Configuration selbst zu bestimmen wo welche Felder in einer Eingabe Maske sind, welche Keys sie später haben welche Properties von Objekten sie ansprechen etc.) Vor einigen Monaten, als es dann um Budget ging, habe ich angeregt, dass wir doch versuchen könnten ein wenig Budget für uns rauszuschlagen damit wir das ganze in ein vereinfachtes System Refactorn können. Um in Zukunft Zeit und Kosten zu sparen. Allerdings hat der Kunde SO wenig erweiterungen für das Frontend gewollt, dass wir das dort nicht unterbringen konnten. Okay, blöd gelaufen, nicht weiter tragisch. Vielleicht beim nächsten Durchlauf. Tja. Vor 2 Wochen machte ich dann eine spannende Entdeckung: Eine neue Build Pipeline im Deployment System unseres Kunden. Mit der Bezeichnung "v2" für das Frontend. Da war ich auch erstmal nicht stutzig, haben wir den Kunden doch erst im letzten Meeting gebeten, dass wir in der Build Pipeline von Node 14 auf Node 16 Upgraden. Besser Node 18. Wegen Langlebigkeit. Dann hab ich es aber doch mal gewagt rein zu schauen, ich bin ja neugierig. Und Plötzlich entdecke ich React befehle - nutzen wir nicht Angular?! Also weiter im Script gestöbert, die Zieladresse des Deployments gefunden und was sehe ich...? Eine 1:1 neu Replikation unseres Frontends was wir für den Kunden bauen. Nur jetzt in React. Vom Zustand her vor gut 2-3 Monaten begonnen. Ohne irgendwas mit uns abzusprechen. Heißt: Sie hatten das Frontend was wir gebaut haben bereits zu Tode verurteilt. Ein ganz schöner Downer für mich muss ich sagen. Wenn du siehst, dass dein eigenes Baby für ein anderes sterben gelassen wird...? Heißt für mich: Es macht vorne und hinten keinen Sinn das Refactoring durchzuführen. Es würde nicht im Ansatz einen Positiven Effekt haben. Alleine der Aufwand dafür ist höher als das restliche Budget dieses Jahr. Sehr, sehr mieses Gefühl

Schreib ein Buch. Ich finde es super wie du echte Erfahrung einbringst. Ich würde es kaufen.

Hallo David, ich betreue eine Legacy-Software, die eigentlich vor 10 Jahren schon abgeschafft werden sollte. Deshalb frage ich mich jedes Jahr erneut, ob es sich lohnt, Teile der Software zu refaktorieren. Ich bin bereits seit etwa 3 1/2 Jahren bei diesem Projekt dabei und wir versuchen, wo immer möglich, Refaktorisierungen durchzuführen. Die Ablösung durch die neue Software zieht sich jedoch hin, da die Legacy-Software auch sehr viele Schnittstellen hat.

Als Koch sehe ich jeden Tag wie meine Arbeit vernichtet wird. Wenn ich wo arbeite und Kunden habe die es Wert sind, liebe ich meine Arbeit. Wenn nicht, bin ich maximal effizient und nutze die gewonnene Zeit für bessere Dinge im Leben. Beruflich und Privat.

Wir befinden uns in genau der beschriebenen Situation und solange die Wartungsverträge laufen, müssen wir auch die Software noch am Leben erhalten sowie gesetzliche Anpassungen vornehmen. Es ist wahrlich eine Qual, weil wir nichts neues Lernen sondern mit Unverständnis über die gemachten Fehler fluchen. Es ist sehr frustrierend und demotivierend in solch eine Software Zeit und Arbeit zu stecken.

Jemand der schon lange in Amerika wohnt (ursprünglich aus Köln) finde ich hat es ganz gut gesagt. Die Deutschen sind wohl immer sehr Prinzipien und stereotypisch gelenkt wohin gegen der Amerikaner nur das nötigste macht. Ordnung schaffen nur um Ordnung zu schaffen ist halt irgendwie sinnfrei und auch nicht (stereotypisch deutsch) effizient. Aber Ordnung schaffen um Probleme zu lösen oder Dinge zu erleichtern ist durch aus effizient und sinnvoll. Ich glaube es ist kein "entweder oder" sondern ein Mix aus beidem an den richtigen Stellen. Im Endeffekt schreibt man ja auch keine Software um schöne Software zu schreiben, sondern um damit Probleme zu lösen. Klar ist das irgendwie auch eine Art Kunst wenn man so will aber diese dient ja nie dem Selbstzweck sondern (meist) der Lösung eines Problemes.

Ich bin grundsätzlich im Lager Qualität, Moderne und Pragmatismus (Abwägung Aufwand/Nutzen) zu finden. Ich finde in diesem konkreten Beispiel muss mehr in die Waagschale geworfen werden als nur diese bipolaren Punkte. Um auf die (hypothetische) Frage zurück zu kommen, kann und will ich micht nicht festlegen. Es kommt auf die Randbedingungen an. Ohne diese zu kennen, könnte ich keine Entscheidung treffen. Emotionen stecke ich nie in die Software die ich schreibe. Ich freue mich darüber, wenn ich an ihr wachsen kann und sie von anderen schnell verstanden und nachvollzogen werden kann.

Nach meiner bisherigen Erfahrung lebt Software sehr oft länger, als es eigentlich geplant war. Außerdem wird eine Software nie komplett "weggeworfen". Entweder werden Module in neuen Projekten wieder eingesetzt, zumindest aber die Erfahrung daraus und erfolgreiche Konzepte und Entwurfsmuster. So sehe ich ein Refactoring einer "fast toten" Software auf jeden Fall als sinnvoll an. Das ist natürlich wirtschaftlich schwierig darstellbar und bei meinen Projekten war das oft der Grund für nicht durchgeführte Refactoring.

Ich glaube, dass wir als Programmierer generell schon zu wenig Qualitätsstandards haben und was teilweise in Produktion geht, wäre als Hardware undenkbar. Ich finde, dass alle Entwickler immer ein Mindestmaß an Qualität liefern sollten. Es sollte uns kalt den Rücken runterlaufen bei Code-Smell und das ganze gerne über Regulierung etablieren, sosehr Bürokratie manchmal nervt.

Ich habe sehr viel mit solcher Software zu tun, die in absehbarer Zeit nicht mehr benötigt wird. Diese ist in 99,99% der Fälle so entwickelt (ich bringe mal den "historisch gewachsen" Klassiker), dass sie weder lesbar, wartbar oder in sonst einer Form als gut zu bezeichnen ist. Ich nehmen mir für diese Fälle immer (!) Zeit, ein Refactoring durchzuführen. Das hat mehrere Gründe: Da ich mich nicht ständig über fehlende Architektur oder sonstige Unzulänglichkeiten ärgern will, wenn ich gezwungen bin, den Code zu ändern, ergibt es für mich immer Sinn, den Code entsprechend anzupassen, so dass er langsam aber sicher meinen Ansprüchen entspricht. Ausserdem lernt man immer noch neue Dinge, wenn man mit so altem Code arbeiten muss und diesen nach eigenen Maßstäben anpasst. Somit ist für mich ein Refactoring niemals vergeudetete Zeit, da ich die Erkenntnisse auch in anderen Projekten nutzen kann, unabhängig davon, ob die Software, die ich aktuell anpasse, nur noch eine begrenzte Lebensdauer hat. Was ich aber auch gelernt habe: Es ist oftmals hilfreich, nur die schlimmsten Entgleisungen der anderen Entwickler zu korrigieren, so dass man ein gutes Bauchgefühl hat, auch wenn man weiss, dass es noch etliche andere Baustellen gibt. Hier gehe ich dann aber ganz pragmatisch und rational vor: Ich setze mir immer Deadlines für solche Anpassungen, ist die Deadline abgelaufen und ich habe kein für mich zufriedenstellendes Ergebnis erzielt, wird an dieser Stelle abgebrochen und nichts mehr an dieser Baustelle "angefasst". Das musste ich über einen recht langen Zeitraum lernen, da ich früher immer nach dem Motto "Deadline ist abgelaufen, aber 10 Minuten kann ich jetzt auch noch dran arbeiten" vorgegangen bin, das habe ich mir mittlerweile strikt abgewöhnt und komme damit auf einen für mich akzeptablen Kompromiss von Aufwand und Nutzen. Es ist aber eine wirklich spannende Frage, auf die jeder eine für sich passende Antwort finden muss. Iich habe für diese Fälle immer einen Blocker für Freitag Nachmittag in meinem Kalender, in diesem Block werden ohne Ausnahme immer die technischen Schulden bzw. Altlasten abgebaut, dabei gehe ich wie oben beschrieben vor. Hat auch den für mich netten Nebeneffekt, dass ich mit einem "noch etwas sinnvolles vor dem Wochenende geschafft" Gefühl ins Wochenende gehen kann. :)

Selbst wenn deine Prinzipien überwiegen macht es mehr Sinn, die Zeit und Mühe für voraussichtlich langlebige Software aufzubringen. Das erste, was man zu prüfen hat, wenn man gute Software machen will, ist, dass man die richtige Software macht.

Hab dein Video erst jetzt gesehen, Antwort kommt etwas später deshalb. Bin jetzt PL und musste aus Technologie Sicht genau eine solche Anwendung erneuern, aber im Wissen sie wird in 2 Jahren ersetzt. Aus diesem Grund haben wir nur den Kern übernommen und der Anwendung ein paar neue API‘s spendiert. Den Core zu erneuern war einfach zu aufwendig für die verbliebene Laufzeit. Mit den neuen Schnittstellen konnten wir ein paar Features dennoch integrieren, so dass der Kunde zufrieden ist und die Software dennoch in würde eines Tages in Rente gehen kann.

Hi David, ich könnte mit dem Refactoring in dem speziellen Fall dann gut schlafen, wenn ich das Gefühl habe, dass es gut genug ist. Das wäre für mich so ähnlich wie mit einem älteren Auto bei dem man genau weiß, dass es noch einmal TÜV bekommt und dann schluss ist. Da macht man auch alles so, dass es sicher ist und man es bedenklos fahren kann. Mehr aber auch nicht.

Es geht nicht immer um Prinzipien oder Bequemlichkeit, sondern einfach darum dass man keine Ressourcen hat um nach allen Regeln der Kunst die Software schön sterben zu lassen. Und der Faktor Zeit spielt mit die größte Rolle bei der Abwägung in welcher Schönheit etwas noch zu retten ist.

Hi David, zu begin des Videos war ich zuerst der Meinung, mit so wenig wie möglich aufwand zu ende gehen lassen, jedoch bei genauerer Betrachtung und der auch der Zeit würde ich Persönlich den Job so Ordentlich wie nur Möglich zu ende bringen. Es geht ja schließlich auch nicht nur um diese bald nicht mehr benötigte Stück Software, es geht ja auch immer um mich als Person, wenn man jetzt sagen wir mal 5 oder 10 Jahre nur noch das nötigste macht, was würde das für einen Zukünftigen Arbeitgeber für ein Bild machen. Und da wir hier auf keine fall von wenigen Wochen Reden, sollte man das immer so sehen was ich heute vebessere könnte mir schon morgen bei meiner Aufgabe helfen.

Wenn die Software modular aufgebaut ist, dann hat sie auch eine Ebene der Abstraktion zum Betriebssystem. Sprich die Software kann immer wieder angepasst werden für verschiedene Betriebssysteme und deren Versionen.

Finde den Einsatz von Software in AKW und anderen Hochsicherheitseinrichtung sehr bedenklich. Eine Modellierung von einer analogen Steckkarte bzw. ein Analogen FPGA würde ich bevorzugen.

Bei einem Atomkraftwerk reden wir ja von vielen Jahren die noch vor der Software liegen. Ich glaube das da 10 Jahre sehr sparsam geschätzt sind. Bei einem Rückbau von Atomkraftwerken rechnet man in Jahrzehnten. Von dem her würde ich es ordentlich machen, denn selbst 5 Jahre sind eine lange Zeit in der Softwareentwicklung.

Sehr interessantes Thema, bin zwar Team Prinzip, aber wenn ich weiss das der Patient bald den abgang machen wird, dann nur soweit, das man nicht unnötig leidet bei der umsetzung. Allerdings wäre es ein anderes Thema wenn doch noch die Wahrscheinlichkeit im Raum stünde, das der Patient spâter doch nochmal von den Toten auferstehen soll. Ist es nicht auch eine Kosten_Nutzenrechnung? Denn wenn die Kosten den Nutzen überwiegen, dann ist es unwirtschaftlich. Das ist aber auch eine echt knifflige Frage.😎

Mir geht's genauso. Auch meine Projekte sind meine Babys, die natürlich nicht sterben sollen. Schauen wir doch mal außerhalb des Monitors. Gasdichter Reißverschluss, kommt aus der Raumfahrt, wird heute beim Tauchen verwendet. Ich würde einfach Klassen/Methoden (wenn wir Java nehmen) aus dem Hauptprojekt "auslagern" und (ggf. modifizieren/refactoren), damit sie in anderen Projekten weiterarbeiten können. Ich vermeide auch oft das Schreiben von Klassen SPEZIELL für ein Projekt, sondern schaue zu, dass ich Librarys schreibe und sie in mehreren Projekten einsetzen kann. Ich code zwar (nur Hobby), bin aber kein Profi.

Der Rückbau von Kernkraftwerken kann Jahrzehnte beanspruchen, siehe beispielsweise Gundremmingen, Block A. Dieser wird einer Havarie 1977 seit 1983 zurückgebaut. Ich weiß nicht, ob sie damit inzwischen fertig geworden sind. Wäre jetzt 40 Jahre her. Wenn man sich mal überlegt, mit welchen Sprachen und welchen Computerausstattungen man vor 40 Jahren programmiert hat. Damals waren in den üblichen Computern zu Hause noch nicht einmal Festplatten verbaut und vernetzt waren die Rechner nur minimal. Ich denke also, dass deine Software viel länger leben wird, als du jetzt denkst, und möglicherweise für den Rückbau anderer Kraftwerke verwendet werden kann, möglicherweise in anderen Ländern.

Grundsatzfragen "Wartungsaufwand oder Problemumgehungsaufwand" sollte man wie Du bereits selbst erwähntest mit Vorüberlegung einschätzen und entscheiden. Den heiligen Gral für real existierende Softwareprojekte gibt es so nicht, auch wenn so manch sehr gutes Theorie oder Java-Lehrbuch / -Vorlesung / -Dozent derartige Allgemeingültig kategorisch für sich in Anspruch nehmen mögen. Praktische Softwareentwicklung sollte dabei folgendes möglichst detailliert kennen und berücksichtigen: a) Ausgangssituation (also Code und dessen gemessenes Verhalten), sowie b) zur aktuell anstehenden Aufgabe verfügbaren Theorien, Techniken, c) Zusätzlich braucht es ein kreativ denkendes Gehirn, um diese Balance in einer konkreten praktisch umsetzbaren Weise durchzuführen. d) Also schematisch angelernte rezeptartige Vorgehensweisen reichen nicht, um neben Zeitdruck weitere Kriterien auszubalancieren "Projektdreieck: Umfang - Qualität - Kosten". Nützlich sind sie aber dann wenn die Ausbalancierung und Entscheidung der Vorgehensweise nun beschlossen und bekannt ist und es jetzt um viele kleine Einzel-Refactoring-Schritte geht. Je länger man sich mit Softwareentwicklung beschäftigt, umso eher wird man in entsprechend schwierigeren, komplexeren Softwareprojekten eingesetzt: alte oder umfangreiche Softwareprojekte. Zumindest war es bei mir so, als junger Techniker/Ingenieur schrieb man selbst eigene neue Software bis diese einen Grad an Komplexität/Reife besaß (s. unten), es folgte Konzentration auf Erweiterung / Anpassung / Modernisierung auch immer zentralere Programmteile (Programmkern) und verantwortungsvollere (Qualität + Leistung) umzubauende Codebereiche (XP+Refactoring) als Teil langjähriger Entwicklung einer Standardsoftware und vergleichsweise wenig darauf aufbauende Anwendungen in Form kurzfristigere kundenspezifische Projekte. So interessant diese Art der natürlichen Aufgabenverlagerung ist, bleibt weniger Zeit für allerneueste SE-Hypes (Programmiersprachen, Bibliotheken, Frameworks, Entwicklungssystem- & Software-Infrastrukturen, Systemadministration). Vor bezahlter Anstellung Softwareentwicklungsingenieur hatte ich als Diplomand das Glück neueste Software-Technik (OOP) für eine damals anwendungsfreundliche PC-Software einzusetzen: eigentlich wurde es Integrierte Entwicklungsumgebung die dem Vorbild der ersten objektorientierten Turbo Pascal IDE nachempfunden war die typische Menüführung Datei - Bearbeiten - Berechnung - Ergebnisausgabe - Hilfe besaß und deren Anwendungsgebiet die Berechnung statischer Balkensysteme mittels Matrizenverfahren der linearen Biegetheorie (vereinfachte Vorstufe der Finite Elemente Methode) war. Übrigens war meine Diplomarbeit eine Neuentwicklung die eine vorhergehende Diplomarbeit ersetzte weil das resultierende Programm schlechte Qualitätskriterien hatte: 1. versteckte Rechenfehler!, 2. umständlichste Bedienung (Zahleneingabe ohne Zifferntasten: jede Zehnerstelle mit + und - zur nächsten Ziffer weiterschalten), 3. wartungsunfreundlichst verschnörkelter Programmcode statt linearer Programmsequenz hierfür eine überflüssige Programmschleife in der jeder Schleifenzählwert von einer Mehrfachfallunterscheidung individuell behandelt wird (also ein als Schleife getarntes Sequenz-Schaf im Schleifenkörper-Wolfspelz).

80/20 Ansatz. Wenn die SW nicht mehr Lange im Einsatz bleibt, würde ich Optimierungsmaßnehmen hinsichtlich Erweiterbarkeit hinten anstellen, Lesbarkeit und Dinge die die Qualitätssicherung einfacher und sicherer machen würde ich durchaus aus in einer solchen Situation priorisieren. Es wird aber auf diese Frage keine allgemeingültige Antwort geben. In meinem Job habe ich täglich mit ähnlichen Abwegungen zu tun und mit der Zeit muss man lernen das Prinzipien zwar schön sind, aber es ab einem gewissen Level nur noch der persönlichen Befriedigung dient. Ich habe daher für mich entschieden, ich - als Entwickler - muss nach wie vor zufrieden mit meinem Produkt sein. Ich muss aber auch den Benefit für den Anwender/Wirtschaftlichkeitsaspekt berücksichtigen und wenn ich dort abwäge komme ich meistens zu einem guten Kompromis. Ich selbst lege dann meist aufgrund meines Perfektionismus nochmal 5-10% drauf damit ich nachts ruhig Schlafen kann, aber man sollte es nicht übertreiben.

Da der Endpunkt der SW mehr oder weniger feststeht, bleiben ja i.G. nur noch wenige Variablen. Was ist wichtiger: 'Schönheit' oder Lebenszeit? Oder eher plastisch formuliert: Was ist wichtiger: virtuelle Babies (SW), oder reale ('Lisa')?

Für mich ginge es bis zum letzten Tag mit vollem Einsatz weiter. Denn ich weiß trotzdem nicht wann die Software tatsächlich ausser Betrieb geht oder wann ein Projekt tatsächlich abgeschlossen ist. Das Ende kann von einem Tag auf den nächsten kommen, oder doch erst in vielen Jahren. Vergebens würde die Arbeit auch nicht sein, da man mit jeder Zeile Code und jeder Betriebsstunde etwas neues über die eigene Arbeit lernt.

Ich würde glaub ich die Änderungen um die Motivation der Mitarbeiter (die dabei involviert sein werden) gestalten. Wo sehen sie (wenn schon das Unternehmen keine Vision mehr hat) ihre Zukunft? Gibt es da auf einer Abstraktionsebene eine Schnittmenge zu dem was jetzt getan werden muss? Wenn eine innere Stimme immer wieder gegen das Refactoring rebelliert nach dem Motto: „Das ist doch eh sinnlos!“, dann wird das unterfangen auch keinen Erfolg haben. Aber: Wenn der Horizont ca. 10 Jahre sind, ist das länger als der übliche Lebenszyklus von Software und damit lohnt sie die Arbeit (zumindest in den SW-Bereichen, die in diesen 10 Jahren noch benutzt werden) Ich würde wie gesagt bei dem People P ansetzen und ihnen klar machen „Hey, der Unternehmenszweck (Energieversorgung) hat sich grundlegend geändert. Es dürfen Dinge neu gemacht werden“, um einen Enthusiasmus zu wecken….keiner reitet gern wissentlich tote Pferde.

Mein erster Gedanke ist, wenn ich die nächsten 5 Jahre ohne Ehrgeiz und Spaß mit dieser Aufgabe beschäftigt wäre und dies bereits abschätzen kann, dann kommt der Job nicht in Frage, easy! Spontan bin ich neugierig, wie 40 Jahre Wildwuchs aussehen, sicherlich eine Herausforderung, dazu eine Arbeitsumgebung mit der ich bisher so überhaupt keine Berührungspunkte habe. Mein Interesse ist geweckt ... doch vermutlich würde ich bereits nächstes Jahr etwas neues suchen. Eine spannende Rundreise wird für mich nicht zum Passion Projekt.

Die Software sollte als Weg des Teams gesehen werden. Wenn das Team danach weiterhin besteht, dann sollten die Entwickler die Zeit nutzen und die Restrukturierung als Fortbildung für sich selbst sehen. Wenn das Budget vorhanden ist, dann wird auf 100% weitergearbeitet.

Schonmal im neuen System Bugs des Legacy-Systems nachgebaut?

Gute Frage was ich machen würde. Im Endeffekt ist die Antwort "was das Management zulässt". Wenn man unter Zeitdruck ist für neue Features, dann hat man so oder so keine Zeit für neue Features. Dann stirbt die Anwendung allerdings auch irgendwann, weil sie nicht mehr wartbar ist...

Ich würde versuchen so gut wie möglich die anderen "Rückbauer" zu verstehen um nur das aufzubereiten was mit den neuen Use Cases jetzt gebraucht wird. Ist kein Atomkraftwerk, aber; Noch in der Ausbildung sollte ich mal 75 Programme von ehemaligen Mitarbeitern (ABAP-scripts von Business-Usern) analysieren. Am Anfang wollte ich noch das Alte möglichst gut dokumentieren, aber vieles war zu dem Zeitpunkt schon Teil von SAP-Standardfunktionalität geworden. Die Kosten/Nutzen Frage hab ich dann je Programm immer früher gestellt und dabei den fachlichen Schwerpunkt der aktiven Kollegen kennen gelernt. Einige gute Programme waren auch dabei, die einfach nur ein Binary statt linear search brauchten. Das nützlichste "Interface" der Aktion war aber wahrscheinlich die Excel-Tabelle mit der Bestandsaufnahme. Wenn jetzt bei dir Abbau-Sicherheit der wichtigste Use case ist, dann hilft ne Karte der Untiefen vielleicht mehr als das Schiff auf Vordermann zu bringen. Kritische Refactorings ergeben sich dadurch wahrscheinlich selbst, und beim fixen von denen ist die Zeit wirklich wertvoll eingesetzt

Möglicherweise habe ich etwas wenig Erfahrung zu dem was ich vorschlage. Aber ich versuch's mal: Ich bin der Meinung es muss nicht unbedingt schön aussehen (also die Attribute Lesbarkeit wird erstmal weit hinten anstehen). Sondern sich festzulegen, was in kommenden Wochen, Monate oder Jahren eine Rolle spielen wird. Ich würde dabei den Fokus auf Erweitbarkeit, Testbarkeit und vor allem die Ausfallsicherheit legen. Ich würde mich erstmal festlegen in welchen Bereichen der Anwendung bewegen möchte. Aber auch Zeiten und Aufwand dafür einsetzen möchte. Dazu muss auch irgendwie die Machbarkeit der Rahmenbedingungen irgendwie überprüft werden. Achja, hab fast vergessen: Ich würde mir inzwischen passendes Entwicklungsmuster überlegen und festlegen. Letztendlich würde ich entsprechend priorisieren und zwar nach Wochen, Monate, Quartale und Jahre. Es muss nicht perfekt sein. Aber definitiv nicht der letzte Dreck. Etwas mühe würde ich reinstecken. Ich würde mich zwischen "ich mach das mal" und beherzt bewegen. Ich weiß, es ist leichter gesagt als getan. Ich hatte auch eine Kollegin, sie wollte alles perfekt machen. Da habe ich ihr gesagt, dass das Ganze viel zu viel Zeit benötigt und der Aufwand sich nicht lohnt, da später beim Einbau eh wieder zerrupft wird. Es soll schon etwas ordentlich aussehen, aber in entsprechenden Rahmen von Zeit und Aufwand. (Am besten so, dass man später den Aufwand erkennen kann.)

Refactoring einer Software die bald nicht mehr genutzt wird ist ja wie Bodenwischen wenn gerade die Überflutung kommt. Also unnütze Mühe. Wichtig wäre vielleicht noch die Daten-Formate zu dokumentieren und zu sichern. Insbesondere wenn es proprietäre Fileformate sind. Damit sie (falls nötig) später nochmal lesbar sind.

Es geht eigentlich um eine Art "Sterbehilfe", denke ich, und dort versucht man dem Sterbenden, den Abschied so leicht und erfüllen wie möglich zu machen, die optimale Pflege und medikamentöse Behandlung zu geben.

Ich denke ein stärkeres Problem ist es für einen Technologieschift bekanntes Wissen über Bord geworfen werden muss. Bringt mich gerade auf den Gedanken: vielleicht bleiben da auch einige Hängen, weil Wechsel zu schleichend ist. Ich finde aber auch die Arbeitskultur ist schon stark unterschiedlich. Insbesondere Inkrementell zu Entwickeln und sich tiefer mit der Domäne auseinander zu setzen fällt meiner Wahrnehmung nach ältern Entwicklern schwerer. Wenn es allerdings um Technologieexperten geht, habe ich den Eindruck, dass da wesentlich mehr ältere Menschen unterwegs sind, die mich wirklich beeindrucken.

Was Du dabei etwas außer Acht lässt: Die Arbeit sollte den Entwicklern auch Freude bereiten, sonst leiden die Mitarbeiter und auch ihre Arbeit darunter. Im schlimmsten Fall kündigt die Hälfte und die Software stirbt vor ihrer Zeit, denn neue Entwickler finden dürfte bei dem Projekt praktisch unmöglich sein. Und auch wenn der Reaktor abgeschaltet ist, sind es immer noch gefährliche Stoffe und der Rückbau kann vermutlich beliebig teuer werden. Ich würde also die goldene Mitte suchen. Testbarkeit und eine gute Testabdeckung sind zwar schön, hilft bei der konkreten Arbeit aber eher wenig weiter. Ich würde stattdessen nach den ganz aktuellen Problemen bei der täglichen Arbeit suchen und so weit refaktorisieren, damit die nächsten Jahre zumindest halbwegs erträglich möglich sind, alles andere bleibt wie es ist, oder wird pragmatisch behandelt, schnelle Lösungen für die "Entwickler-Usability". Wie weit das geht, muss dann das Team für sich entscheiden, UnitTests gehören da mMn. nicht mehr dazu, eine vernünftige Schichtentrennung (oder Aufgabentrennung, Featuretrennung, etc.) allerdings schon.

Es wäre für mich eine Frage des Preises. Wenn der so oder so gleich wäre, dann würde ich das Team betrachten. Sind viele motivierte Entwickler dabei? Sind newbies dabei, die noch was lernen würden, wenn man es "schön" macht? Wenn ja, dann wäre das ja ein guter Preis. Wenn nein, dann dirty 😂

Wenn sich die Investition für zukunftsfähige Dinge nutzen lässt (Für spätere Projekte) dann würde ich da Zeit reinstecken. Da das System Atomkraft an sich ein großer Bug ist und nun endlich stirbt würde ich die Sache mitsterben lassen. Wie lange wird das noch genutzt und wieviele Änderungen sind zu erwarten ? Auf mehr als nötig würde ich nicht gehen. Nutze die Zeit für wichtige Dinge die Zukunft haben.

Ich hatte früher (am Ende meines Studiums) den Anspruch, richtig gute Software abzuliefern. Und dann wurde ich mit der Realität konfrontiert. Budget und Deadlines sind limitierende Faktoren. Ich versuche immer noch, gute Software abzuliefern, aber eben nur soweit das in den gegebenen Grenzen möglich ist. Ich habe schon Software geschrieben, die nur für einen einzigen Releasewechsel verwendet wurde. Auch die habe ich gut lesbar und modular geschrieben. Software soll in 10 Jahren voraussichtlich abgeschaltet werden? Das ist ein verdammt langer Zeitraum. Da lohnt sich Refactoring bestimmt.

Emotionen gehören da nicht hin. Mache Refactorings wo es einen ROI in Sachen Erweiterungen, Performance oder BugFix gibt. Oder gehe ins BugFix in den Bereichen wo die Anwendung noch sehr Stark benutzt wird. Die Energie mit Qualität stecke lieber in neue Projekte. Oder du kannst Teilbereiche der Anwendung als Services neu schreiben, welche später für weitere Anwendungen im Energiebereich / Verwaltung weiter verwendet werden können. Viele Grüße aus dem schönen Bremen ;-)

Für mich ist es auch eine Befreiung zu Wissen dass eine Software und die technische Schuld mal beerdigt werden kann. Auf der anderen Seite kannst du nicht wissen wer den letzten Stand der Software nicht doch woanders weiter nutzen zu wollen. Für diese Geistkunden/Geistnutzer das jetzt anzugehen ist auf jedenfalls nobel. Bringt aber selten Geld ein. Für seine eigene Sanity den Code anzugehen kostet Zeit, je nach Größe des Programms auch viel mehr als zuerst angenommen. Aber es gibt noch einen anderen Grund warum es sinnvoll sein kann solch ein Programm, das trotzdem kurz vor dem Exitus steht, noch zu refactoren. Möglicherweise findet man dadurch Fehler oder mögliche invalide Zustände, die durch "Bugfixes" an anderer Stelle mitigiert werden mussten um daraus zu lernen und nebenbei die technische Schuld loszuwerden. Also ich verstehe die Problematik und der Grund für die Schlafbeeinträchtigten Nächte... Aber es trotzdem anzugehen kann sinnvoll sein. Edith: Schade dass mir das Video jetzt erst aufgeploppt ist.

7:49 Was jetzt kommt finde ich LoL gut. Allgemein wird Top - Down gefuscht, geschlampt, getrickst. Wenn so etwas ansteht braucht man Personal, was nach dem alten System Geld verdient und eine neue Truppe, die sich auf refactoring konzentriert , Prozess - und Qualitätsmanagementoptimiert ein Projekt abarbeitet und dann den Leuten die bis jetzt mit dem alten System Geld verdient haben coachen , so wird es gemacht sonst gibt es keine Freigabe. Keiner kann eines Tages mehr produktiv arbeiten.

Ich würde den Code radikal vereinfachen. Alles, was nicht benötigt wird, löschen. Sollte es überraschenderweise doch benötigt werden, hat man es ja in der Versionsverwaltung. Sind einfachere Algorithmen gut genug? Müssen neue Anforderungen mit dem alten System gelöst werden, oder kann man, beispielsweise die Programmiersprache Q benutzen?

Ich würde das Thema vom Kosten/Nutzen Aspekt angehen. Wenn mich das Refactoring mehr als ca. 20% der zu erwartenden Restlaufzeit kosten würde, dann würde ich ganz hart kalkulieren, wieviel Zeit mir das Refactoring, im Angesicht der zu erwartenden neuen Anpassungen, ersparen würde. Erspart es mir nichts, muss auch nichts geändert werden, da es niemandem nützt. Ein Refactoring sollte bei neuen Zusatzmodulen zumindest die Zeit einsparen, die das Refactoring gekostet hat, ansonsten ist das Hobby aber keine sinnvoll und professionell investierte Zeit.

Wenn klar ist, dass die Software neu geschrieben wird, würde ich den Code dreckig sterben lassen und möglichst minimalen Aufwand investieren um ihn so lange wie nötig am leben zu halten. Auf der anderen Seite hält aber nichts so lange wie eine Übergangslösung. Ich würde mir also für die neuen Komponenten die entwickelt werden, wenigstens noch Mühe geben :D Das Hauptproblem ist auch oft, dass Software manchmal nicht wirklich austauschbar ist. Also selbst wenn das Code refactoring irgendwann losgeht, wird der Legacy Code womöglich eine sehr lange Übergangsphase haben. Es ist ein sehr komplexes Thema, da sowohl die alte Software, als auch das Refactoring extrem teuer sein kann. Hier gibt es glaube ich kein richtig oder falsch. Ich arbeite im Extremfall, wo sowohl eine neue Architektur für ein altes Projekt aufgebaut wird, als auch die alten Komponenten in der alten Architektur gerefactored werden. Beim Refactoring ist insbesondere das Problem, dass der Code kompliziert ist und keine Testabdeckung vorhanden ist. Um den zu refactoren, werden teilweise erstmal Tests für den alten Code geschrieben. Ja - geht auch anders. Schön ist die Situation aber niemals. Der Aufwand der betrieben wird ist riesig ... die Kosten die dabei entstehen sind es auch! Wie mans richtig macht, weiß aber niemand so wirklich. Am Ende hoffen wir, gemeinsam in die richtige Richtung zu laufen

Bücher wie Clean Code oder Clean Architektur sollten für Softwereendwickler eigentlich Pflicht sein und das obwohl besagt Bücher auch lange nicht perfekt sind

Interessante Frage. Bin auch im Team Prinzipien unterwegs. Schreibe an einer Software, die wegen gesetzlicher Vereinheitlichungen in Zukunft die ganze Komplexität eigentlich nicht mehr benötigt, die wir bisher aufgebaut haben. Habe trotzdem Tests für den ganzen komplexen Kram geschrieben. Am Ende fällt doch einiges an Erfahrung und Softwarekomponenten ab, die ich später wieder gebrauchen kann.

Einerseits sehe ich das konkrete Beispiel politisch, weil Kernkraftwerke nicht nach privat-betriebswirtschaftlichen Gesichtspunkten geführt und finanziert werden sollten. Die "Wirtschaftlichkeit" sollte in diesem speziellen Fall also kein Entscheidungskriterium sein. In jedem Fall wären aber folgende Überlegungen sicher sinnvoll: Wie lange wird der Prozess vermultich dauern, das Refactoring/die Refactorings vorzubereiten? Triage: Was lohnt sich in Anbetracht der zu erwartenden Entwicklungen in den nächsten 10 Jahren zu refactoren, und was weniger? Und, für den vom eingangs erwähnten Ideal abweichenden Praxisfall: Welche Ressourcen werden voraussichtlich zur Verfügung stehen? Etwas, was sich in dieser Situation aber mit einer grossen Wahrscheinlichkeit lohnt (und sei es schon nur für potentielle Refactorings) sind Arbeiten an Dokumentation und ggf. Tests, falls diese entweder veraltet sind oder Lücken aufweisen. Das ist auch bei Zeitfenstern der Fall, die kleiner sind als 10 Jahre, besonders in Fällen, in denen die Software anschliessend abgelöst werden soll (nicht vergessen: Tests sind u.a. auch Dokumentation).

immer wenn die Lizens endet... 😂 denkt man drüber nach... seit 10 Jahren quasi stillstand was updates angeht... dem Entwickler auf die Sprünge zu helfen ist sehr schwer, da dieser lieber weniger arbeiten möchte, statt mehr. Als Monopol-Inhaber muss man das ja nicht, gibt ja niemand der es annähernd könnte oder getan hatten/täte. Übers reengineering zum Ziel. Bist auf jeden Fall aboniert, gefunden durch den algo der startseite hier. Unglaublich, weil never see this in search before. Bin auch ,mal auf den Aufwand gespannt, anstatt Sprache auswählen und code selber neu schreiben. Team 110%... kommt aufs Ergebnis an, ...muss als gepimptes Orginal schon glänzen,... als miserabel Programm in code übersetzt zu haben.. für andere merkbar... lieber das erstere. optimierung liegt mir aber eher, als mich gut zu fühlen beim schlecht arbeiten.. 😏 Perfektionismus als Todesursache ist nicht witzig, was beim selbstgecodeten Babys aber meistens genau dazu führen kann. Kommt halt auf die eigene Einstellung an, und wie das Projekt oder die vielen kleine, aus deiner sicht wirken. Verbesserungswürdig, oder die Zeit nochmal reinstecken die der eigentliche Entwickler selber schon. Da ist die Relation zum ,,einfachen" verbessern, weil es ja schon tut und getan hat, zu groß, als wenn man sein Baby in den Ring wirft, und ansehen muss, wie deformierte Gedanken in Gestalt aus-sehen/fallen können... wo doch compilen ohne fails geklappt hat, ... ich wage zu bezweifeln, das man eigene Probleme, allein besser gefixed bekommt, als wenn jemand anderes drüber schaut. Aus Gründen bin ich lieber der Zweite 🤣 lobloot farmen 😎 hab ma gehört, man soll nich auf sinkende Boote springen, ... da ne gute motivation hinzukriegen, .. ,,ihr System ist nun viermal so schnell, dank der optimierung,, und zweifach so produktiv im ganzen, ... wäre es ... im prinzip .. hätte es schon früher sein können, ... so wenn sich eine Sinnlosigkeit bemerkbar macht, wo die zeit den sinn nicht ergibt, .. und spätestens wenn der Gedanke kommt, dann wird es Zeit geworden sein ...

Zuerst musst du mit deinen Ressourcen vernünftig umgehen also ökonomisches Prinzip. Wenn Du jetzt alles perfekt machst kannst du in der Zeit anderen Entwicklern oder Projekten nicht helfen und auch keine Videos aufnehmen (Opportunitätskosten). Falls es ein Repo gibt würde ich mir eine Statistik erstellen lassen welche Dateien, Module und Klassen am häufigsten in der Vergangenheit verändert wurden. Dies ist zumindest ein Hinweis, dass dieser Code zukünftig häufig gelesen bzw. weitere Änderungen und Erweiterungen nötig haben wird. Genau hier würde ich dann Refactorings durchführen und mich zuerst auf die Low Hanging Fruits konzentrieren.

ist ne abwaegungs sache, die Abschaltung haette ja auch noch weiter verzoegert werden koennen. und dann gibt es bestimmt auch externe anforderungen (was weiss ich von der international atom sicherheits behoerde.) Bei einem Atomkraftwerk wuensche ich mir das du da die hoechst moeglichen standards ansetzt. ich frage mich ob du falsche entscheidungen aus der vergangenheit benennen kannst, Sei es eine technologie oder code entscheidung. Also, wenn man jetzt nen game entwickelt, kann man vielleicht erstmal ne einfach programmierte version machen,... und damit sehen ob das ueberhaupt spass macht, aber bei wirklich relevanten Applicationen sollten die hoechsten anforderungen erfuellt werden. Ich bin selbst ein grosser Fan vom refactoring und schnellem progress machen. da darf die qualitaet auch mal leiden, aber man muss ehrlich zum code bleiben. wenn er schlecht ist, dann darf der auch veraendert werden. Aber ich hab auch schon faelle gesehen wo ich den code schlecht finde, aber man muss erst warten bis der entsprechende Entwickler stirbt (oder das Projekt verlaesst). Ein anderer Gedanke,... ach ich mach nen zweiten Kommendar,...

Ich finde rationale Abwägung am besten statt falschen Perfektionismus. Teile die erweitert werden müssen, müssen "begehbar" sein. Andere Teile der Software können gerne ruhig sterben. Denn auch ein Refactoring ist auch eine Gefahrenquelle. Man kann das mit echten Abrissbaustellen vergleichen. Es wird ein Zaun aufgebaut damit der Staub und ähnliches nicht die Baustelle verlässt. Die Zugänge für die Arbeiter müssen begehbar sein und dürfen keine Unfallgefahren beinhalten, aber eine Tapete ist unnötig. Auch die Zufahrten zur Baustelle brauchen Amplen usw.. Es kann sich also lohnen Teile, die mit zukünftigen Erweiterungen zusammenarbeiten sollen mit Adaptern zu neueren Architekturen kompatible zu machen, anstatt den grundlegenden Algorithmus oder die Komponente zu refactoren. Diese Entscheidung kann in jedem Abschnitt anders ausfallen. Deswegen passt das Team "Prinzipien" nicht. Das Team "Bequemlichkeit" passt auch nicht, da es ziemlich unbequem ist jeden Abschnitt zu bewerten. Ich würde sagen Team "Prinzipien" und Team "Bequemlichkeit" sind hier sehr ähnlich, da beide den gewohnten Gang beinhalten. Gewohnheiten sind aber meist bequem. In diesem geschilderten Fall sind es gerade nicht die Gewohnheiten die helfen. Es stellt sich bei desem Vorgehen aber auch die Frage, ob man genug Zeit hat all diese Abschnittsentscheidungen zu fällen. Hier könnte aber eine graduelle Anpassung helfen: Man kann die Granularität der Abschnitt auch wählen. Modulebene, Klassenebene, Methodenebene und ähnliches. Je feiner umso mehr Abschnittsentscheidungen.

Egoistisch gesehen ist jedes Problem, dass ich löse, eine Lösung, die mich weiter bringt. Von daher könnte ich sogar mit Motivation post Mortem des Projekts noch fixen. Aber das AKW ist eine interessante Sache. Niemand weiß, ob es nicht wirklich wieder angeschaltet werden würde. Und selbst in der Restlaufzeit könnte etwas passieren, was man zeitnah fixen möchte. Ich würde mir für das Refactoring als eher kritische Bereiche aussuchen... ob das Backoffice den Strom richtig abrechnen kann wäre mir zum Beispiel wichtiger als die Sensorik, Kühlkreis, Reaktorkontrolle. Nicht.

Ich verstehe die Überlegung, ticke da allerdings völlig anders. Auch mir ist wichtig, dass der Code den ich liefere möglichst gut ist, fehlerfrei, etc. Allerdings verliere ich schnell die Motivation, wenn ich merke, dass ich für die Mülltonne arbeite. Also wenn es bspw. heißt "Wir müssen morgen dem Kunden noch mal was präsentieren, dafür müssen dringend Fehler X, Y und Z in der UI behoben werden.", ich aber gleichzeitig weiß, dass das UI-Refactoring schon im Gange ist, dann nervt mich so eine Aufgabe eher und ich würde wirklich nur noch QuickFixes machen. Für mich würde Software, deren Ablaufdatum so klar definiert ist, auch bedeuten, dass ich nur noch die klar definierten Anforderungen erfülle. Man muss natürlich aufpassen, dass man sich die Arbeit "down the road" nicht unnötig schwer macht. Also wenn ich es mal mit einem Auto vergleiche, bei dem festgestellt wird, dass der Unterboden rostet und der nächste TÜV garantiert nicht mehr bestanden würd, dann würde ich ja den Heckspoiler auch nicht mehr lackieren, auch wenn ich das vielleicht mal vor hatte. Man macht halt ggf. noch den Ölwechsel, achtet drauf, dass das Fahrzeug einigermaßen sauber ist, etc... aber man verpasst dem Fahrzeug dann ja sicher auch keine neue Auspuffanlage mehr oder dergleichen. Egal wie sehr das Auto vielleicht ein Liebhaber-Stück ist, sind die Tage halt gezählt. Ich kann mir nicht vorstellen, dass noch super viel Zeit und Arbeit von irgendjemanden in so ein Auto gesteckt werden würde. Wäre es da bei Software wirklich anders? Und falls ja, was wäre die Motivation dahinter?

Ich bin eher im Team "Prinzipien" (oft zum Verdruss meiner Vorgesetzten)... Aber ich kann einfach nicht mit Pfusch leben!

Die wichtigste Frage ist, wer bezahlt das Refactoring und wie lange würde es dauern, den Sch...code in einen sauberen Code umzuwandeln. Während des Refactorings muss ja mit dem alten schlechten Code weitergearbeitet werden und ich vermute, dass der Kunde die Anpassungen so schnell wie möglich haben möchte. Daher würde ich das Refactoring nur auf die Teile beschränken, wo es ständig knallt und zusehen, das der Mist irgendwie am Laufen gehalten wird und danach mich neuen Projekte widmen, wo diese Fehler von Anfang an vermieden werden. Also aus den Fehlern der Vergangenheit lernen. Dieses einfache Prinzip lässt sich übrigens auf alle Bereiche des Lebens anwenden. Würde dies bspw. von unserer Politik beherzigt, so würde nicht immer wieder unnütz Geld zu Fenster rausgeworfen.

Nicht Prinzipien vs Bequemlichkeit sollten entscheiden, sondern die erwarteten Kosten bis zum Ende der Lebensdauer beider Optionen. Müssen die Anwendungen aufgrund geänderter und neuer Anforderungen, die durch die neue "Betriebsart" des Kraftwerks entstehen, stark angepasst werden? Dann lohnt sich allenfalls ein zielgerichtetes Refactoring sehr. Wenn nicht, gehe ich davon aus, dass die Anwendungen sehr reif sind und nur noch wenige relevante Fehler vorhanden sind. Dann sollte man das erhebliche Risiko und die Kosten eines Refactorings wohl eher meiden.

ich bin ein fauler entwickler, daher schreibe ich alles so quallitativ hochwertig wie möglich, um beim nächsten besuch so wenig arbeit wie nötig zu haben.

Kommt darauf an, wie ich zu der Software stehe. Ist sie immer noch mein "Baby" oder inzwischen eher der "Onkel", um den man sich nur noch kümmert, weil es sein muss. Ich habe alte Projekte in die ich immer noch gerne meine Zeit investiere; bei anderen bin ich reiner Pragmatiker. Und wie bei mir, so glaube ich geht es bestimmt den meisten: man hat seine Lieblinge.

Sicherheitskritische Bereiche haben Vorrang, um keine Sterbevorgang-bedingten Sicherheitsprobleme zu riskieren. Wer will schon 5 Minuten vor 12 ausgerechnet beim Rückbau einen GAU? Rückfrage: Was soll die betroffene "sterbende Kernkraftwerk-Software" denn überhaupt machen? a) Hochkritische Aufgaben, die bis zum letztmöglichen Zeitpunkt vollautomatisch zuverlässig erledigt werden sollen, vielleicht weil nur die Software dies kann/darf mangels Fachpersonals (Kühlsystem-Regelung, Kraftwerksleitstandanzeige, Robotersteuerungsautomation)? oder eher b) Nebenaufgaben (Verwaltung/Buchhaltung/Personalplanung/Lagerhaltung/Simulation-Übungseinsatz) die zuerst ausläuft, weil zu verwaltendes Personal+Material nicht mehr verfügbar?

Also COBOL ist bei uns noch Ausbildungsinhalt xD

Die entscheidende Frage wieviel Zeit darin investiert wird, ist eigentlich ganz einfach: Wieviel von dem Quelltext kann ich für andere Projekte wiederverwenden?

Kommt drauf an, für wann der Todestag der Software datiert ist. Wenn da jetzt noch 2-5 Jahre dran stehen, dann jo, räum auf. Wenn das Ding in 12 Monaten abgeschaltet wird, dann würde ich nur Kleinigkeiten aufräumen. Bringt ja nichts, da noch großen Aufwand rein zu stecken. Ist am Ende vermutlich auch eine Frage der Wirtschaftlichkeit. Beispiel: Feature/Bug X braucht ohne Refactoring 4 Wochen zur Umsetzung Feature/Bug X braucht mit Refactoring 1 Woche zur Umsetzung + 2 Wochen Refactoring. Dann würde ich natürlich refactoren, selbst wenn in 3 Monaten schon der Stecker gezogen wird. Ich weiß natürlich, dass die Abschätzungen in der Realität nicht so einfach sind.

Wenn du mit "leben" die Benutzung der Software meinst, dann hat die innere Qualität keine Bedeutung mehr. Die fachliche Korrektheit jeder Software ist wichtiger als dessen Codequalität. Wenn Software nicht benutzt wird (und soll), dann ergibt die Weiterentwickelt auch keinen Sinn. Wenn eine Weiterentwicklung in der Zukunft nötig sein wird, dann sollte direkt vorher das Refactoring eingeplant werden und erfolgen, nicht nur wenn eine Weiterentwicklung nur *theoretisch in Aussicht steht*.

Wir behüten unsere Babys, schaffen ein optimales Umfeld für sie um auf "alles" vorbereitet zu sein. Wissen wir genaueres über bevorstehende Herausforderungen können wir das besser machen, unsere Energie bündeln. Ändern sich aber die Umstände dann haben wir plötzlich Schwachstellen - wie ein Knochen der nur in Richtung der Primärlast optimal strukturiert ist (kallus). So traurig das aber ist: Wird unser Baby sterben dann versuchen wir den ABGANG zu optimieren, d.h. wir fokussieren uns darauf die schmerzen möglichst gering zu halten - selst wenn das der Leber schadet.

Wäre für mich jetzt recht eindeutig, wenn es keinen Benefit gibt, ein Refactoring zu machen, sollte man es nicht machen, denn dann würde nur unnötig Arbeit investiert und Kosten entstehen. Aber auch nur, wenn es wirklich keinen Gewinn für die Software darstellt, wie in diesem Fall, weil sie zu dem Zeitpunkt zu dem es sich wirklich als Vorteil erweisen würde, die Software nicht mehr in Betrieb ist.

Ich finde nicht, dass die Wahl "Software einfach sterben lassen" tatsächlich die "bequeme" Variante ist. 10 Jahre lang noch technische Schulden mitzuschleppen und womöglich noch mehr aufzubauen hört sich für mich nach einer einzigen Qual an! Refactoring führt ja nicht nur zu besserem Code bzgl Lesbarkeit usw. sondern auch dazu, dass man etwas darüber lernt und den Code mehr schätzt. Insofern wirkt sich Refactoring nicht alleine auf die Software aus, sondern auch auf den / die Entwickler*in. ;-)

Letztendlich hängt das von den Umständen ab und was das für eine Software ist. Ich hänge zwar auch an meinen "Kindern", aber ich bin auch sehr logisch veranlagt. Und meine Logik siegt meistens über die Befindlichkeiten. Der Aufwand muss dem Ertrag angemessen sein. Wie das nun in dem Fall ist kann ich nicht sagen, weil in dem Video dazu viel zu wenig Information war. Und so eine Frage allgemein zu beantworten ist Zeitverschwendung, weil es auf sowas keine allgemeingültige Antwort gibt.

Die Software, an der ich mitarbeite ist sicherlich kein Atomkraftwerk, sondern nur ein ERP für Handel, d.h. es hängen nicht die Leben von halb Europa dran, wenn was schief gehen sollte (ok, Lingen ist inaktiv, ich weiß), aber dennoch ein paar Familien und deren (Über)Leben. Dieses Programm wird dann auch noch 10 oder 20 Jahre laufen, auch wenn die Programmiersprache vollkommen veraltet ist (Clipper). Erweiterungen mache ich so, dass ich die Teile, die erweitert werden müssen refaktorisiere und ein neues Modul in C# als modular monolith anbaue. Die Kommunikation läuft über REST APIs. Es ist zeitlich nicht anders möglich, weil die Komplexität des Original-ERP immer weiter steigt. Die deutsche Gesetzgebung zwingt uns durch straffere Regelungen dazu. Mit und mit könen alte Teile so auch ersetzt werden. Im Falle der Software des AKW würde ich das genauso machen. Frieden finden mit dem alten Code, ggf. öfter drüber ärgern und furchtbares anpassen und erweiterbar machen und doch etwas neues dran, von dem man weiß, dass es später noch leben wird (zumindest in meinem Fall).

Dass die Software in ca. einem Jahrzehnt angeschaltet wird, ist doch völlig normal. Für Software ist das eine Ewigkeit. Je mehr Weiterentwicklungsbedarf in dieser Zeit besteht, desto eher wird sich das Refactoring auszahlen.

Ich glaube ich wäre im Team "Wirtschaftlichkeit", weil der Kunde muss ja alles bezahlen und warum soll der Kunde für einen Goldstatus bezahlen, wenn er tatsächlich nur Bronze braucht? Ich glaube der Berufsstolz ist ein individuelles Problem, welches aber eben des Coders selbst Problem sein sollte, als Dienstleister darf ich nicht mein "Luxusproblem" vom Kunden bezahlen lassen. Natürlich unterstelle ich dir nichts, ich will nur darauf hinweisen, dass ein Auftrag immer im Sinne des Kunden ausgeführt werden sollte.

Refactoring - ein altes und immer gleiches Lied :) Der BWLer sieht den Sinn nicht - nur Kosten. Der Entwickler sieht den Untergang vom System kommen. Wo treffen sich beide am "Doom Day!" :) #1 Mein Baby: Ich finde dieses Mindset schlecht. Es ist eine Auftragsarbeit. Ich werde für Entwicklung, Wartung und Betrieb bezahlt. Aus die Maus. #2 Persönlicher Anspruch: Software ist in vielen Dingen Handwerk und nicht Kunst! Ich werde dafür bezahlt ein sauberes und funktionales System zu liefern. Ein Handwerker wird Normalfall auch keine intakten und akzeptablen Dinge einfach mal umbauen! Warum auch - es ist für den Zweck gut genug. #3 Refactoring: Wenn was kaputt ist bzw. ein Bug hat - kann man diesen Ort sich betrachten und überarbeiten. Er soll funktionieren, pflegbar und verständlich sein - aber ohne goldene Wasserhähne! Dafür zahlt niemand und keiner hat danach gefragt. Hier finde ich die Methodiken YAGNI und KISS sehr zutreffend. In Büchern wie "Refactoring: Improving the Design of Existing Code" gibt es Ideen und Ansätze wie man an das Thema rangeht. Hier wird auch das Verursacher-Prinzip verfolgt: "Wenn Du an etwas arbeitest - hinterlasse es besser als zuvor!" Räum auf, Ordne Klassen und Code etc. damit beim nächsten Mal besseres Verständnis und mehr Qualität Einzug findet. Aber! Ohne eine definierte Aufgabe oder Grund zur Handlung ist es reiner Selbstzweck und Narzissmus, warum: "Weil der Entwickler/Architekt es halt kann!" Und hier verletzt er die Ehre des guten Handwerks! Refactoring ja -da wo es benötigt wird, wenn es nötig wird und den Punkt für "Gut ist gut genug finden."

Wenn ich wüsste, die Software stirbt, dann lohnt es sich Refaktoring nicht. Ich würde Bugs so gut es geht fixen im bestehenden Code und neue Features separat realisieren mit gut designtem Code und diese sauber über Schnittstellen separieren.

Ich bin froh, daß ich da raus bin und den Fortran Code aus den 70ern nicht mehr sehen muss. Nachdem ich die Quasi von Lochkarten auf 64 Bit portiert habe.

Interessantes Thema. Aber Herr Tielke ist selbsständig. Die meisten Entwickler sind angestellt und viele haben Vorgesetzte, die an der Wartung Geld verdienen. Solange der Kunde zahlt, sind Fehler in der Software wichtig. Erst wenn die Kunden bemerken, dass diese betrogen werden, wird das Wehklagen gross.

Ist denn der Auftraggeber überhaupt bereit für diese Mehrleistung zu bezahlen? Hier gibt es mehrere Interessen. Der Auftraggeber möchte Geld sparen. Also den minimalsten Aufwand betreiben damit man noch bis zum Ende über die Runden kommt. Dein Interesse ist gute Arbeit zu leisten. Damit hältst Du Deinen Standard hoch und wirst nicht zu einem schlechten Entwickler. Lernst vielleicht noch was, anstatt beim nächsten Projekt eventuell schludrig zu werden. Nach dem Motto "Auch wenn morgen die Welt untergeht pflanze ich heute noch einen Apfelbaum". Der Anwender möchte bis zum Ende ein gutes Produkt haben. Die Programmierkosten werden vielleicht eingespart aber an anderer Stelle wird es vielleicht teuer ( Teure Fehler, Mehrarbeit für den Anwender ). In der Konstruktion gilt der Spruch "So gut wie nötig, nicht so gut wie möglich". Der Rest der Welt wird aber dankbar sein, wenn das Kraftwerk nicht wegen einem Fehler hochgeht ( Was nach Deiner Beschreibung aber nicht passieren kann ). Es wird wohl auf einen Kompromiss hinauslaufen zwischen Perfektion und Chaos. Und was ich heraushöre gehst Du eher in die Richtung Perfektionismus, daher wäre meine Empfehlung das Lenkrad in Richtung Chaos zu drehen weil dein Lenkrad einen Drall in Richtung Perfektion hat. So findest Du vielleicht die goldene Mitte.

Wenn es dich ärgert und du genervt bist, dann musst du diese Software eigentlich verbessern - einfach nur damit es aufhört dich zu nerven.

Na dann tue ich dir den Gefallen und äußere mich. ABER, bitte antworte auch! Vorab: Ich schau dich erst seit ein paar Tagen (ca. 7 Videos). Ich entwickle Software/OS für eingebettete Systeme seit 25 Jahren z.B. die Firmware für LED Module in Pkws. So sehr mir meine eigene Software am Herzen liegt, aber mit der Aussicht auf nur wenige Jahre Nutzen würde ich mich nur noch um Bug-Fixing und nötige Erweiterungen kümmern. Es macht für mich keinen Sinn ein Refactoring durchzuführen wenn die Software das nicht mehr braucht/nicht mehr genutzt werden kann. Es gibt beim Refactoring der alten Software bestimmt noch etwas für mich zu lernen, OK. Aber mir erscheint es wichtiger Bugs zu fixen und durch das Refactoring die Stabilität der Software nicht zu gefährden. Es ist ja immerhin für ein Kernkraftwerk...

Solche Software sollte wenn es geht immer noch gut lesbar und vor allem Bugfrei bleiben. Erweiterter ist dann aber nicht mehr das wichtigste.

Wenn der Kunde Geld in die Hand nimmt für ein refactoring spricht nichts dagegen. Und jedes Projekt wird irgendwann legacy.