Warum Software unbegrenzt schlecht werden kann – und warum Metaphern wie das sinkende Schiff trügerisch sind
There's No Limit to How Bad Code Can Get
Zach Kehs, ehemaliger Amazon-Entwickler, argumentiert, dass Metaphern wie „sinkendes Schiff“ für Codebasen irreführend sind. Ein Unternehmen kann untergehen, aber Code hat keinen Boden: Er kann sich unendlich verschlechtern. Technische Schulden kennen keinen Konkurs, keinen Reset. Anhand seiner Erfahrung mit einem riesigen Legacy-System bei Amazon zeigt er, warum Umschreibungsversuche scheitern und wie falsche mentale Modelle zu schlechten Entscheidungen führen.
Software unterliegt keiner solchen Einschränkung. Der Code kann immer schlechter werden. Es kann immer eine neue Indirektionsebene oder eine Leistungsminderung geben.
- ChrisMarshallNY
Einer meiner ersten Jobs war der eines Wartungsingenieurs für eine Codebasis mit über 100.000 Zeilen FORTRAN IV aus den 1970er Jahren.
Keine Kommentare.
Keine Unterprogramme (was wir heute "Funktionen" nennen).
Keine Variablennamen länger als 4 Zeichen.
Spaß. Das effektivste Debug-Tool war ein Ouija-Brett. Es machte mich zum Experten im Raten.
Es ist der Hauptgrund, warum ich heute so penibel auf Codequalität achte. Ich möchte niemanden sonst je diesem Zustand aussetzen.
Übrigens: Mit den heutigen LLMs gibt es wirklich keine Ausrede mehr für schlecht dokumentierten oder schlecht formatierten Code. Man kann tausend Zeilen kommerziellen Spaghetti-Code schreiben und das LLM bitten, ihn zu formatieren und zu dokumentieren.
- lukasgelbmann
Aufschlussreicher Artikel. Der Autor macht einige gute Punkte zur Dynamik technischer Schulden in Organisationen.
Ich denke jedoch, dass ein sinkendes Schiff eine ziemlich gute Metapher ist. Ein gesunkenes Schiff ist ein schreckliches, furchtbares Ergebnis.
In der Metapher ist eine Codebasis gesunken, wenn es nicht mehr tragfähig ist, sie weiterzuverwenden. Die Organisation hört auf, daran zu arbeiten, und führt sie nicht mehr aus. An diesem Punkt ist der Code für das Unternehmen völlig wertlos, wie ein Schiff auf dem Meeresgrund. Zugegeben, man könnte sich theoretisch vorstellen, dass der Code noch schlechter wird. Aber in der Realität wird er einfach nur dasitzen und verrotten.[0] Das Unternehmen könnte einen Neuschrieb versuchen oder das Produkt einfach einstellen.
Es ist möglich, aber nicht garantiert, dass ein Unternehmen mit einer seiner Codebasen untergeht. Das kann auch mit einem Schiff passieren, wenn ein Unternehmen stark davon abhängt.
- blevinstein
> Technische Schulden haben keinen Bankrott, keinen sauberen Neuanfang
Es gibt definitiv eine Option des Bankrotts für technische Schulden.
Man kann die Verwendung eines bestimmten Codes oder einer Technologie einstellen, z.B. indem man sie ersetzt (durch neuen Code oder eine Drittanbieter-/Vendor-Lösung) oder ein System oder einen Geschäftsprozess neu architekturiert, sodass die Funktion des Codes nicht mehr benötigt wird.
Das ist genau das, was die Metapher der technischen Schulden bedeutet. Kurzlebige Systeme können viel technische Schulden ansammeln, ohne dass dies so problematisch ist, weil man plant, bald Bankrott anzumelden (den Code zu veralten und außer Betrieb zu nehmen); langlebige Systeme müssen planen, ihre technischen Schulden in den üblichen Raten abzuzahlen.
- socalgal2
Zwei Dinge
1. LLM kann das meiner Erfahrung nach beheben. Ein LLM, besonders die moderneren, hat viel mehr Kurzzeitgedächtnis als die meisten Menschen (oder zumindest viel mehr als ich). Sie können durch diese Art von Code graben und alle Randfälle herausfinden, Tests schreiben, verschiedene Wege vorschlagen, um Dinge zu verbessern, und dann diese Wege ausführen. Auf Anfrage richten sie bereitwillig Entwicklungs- und Staging-Systeme ein, was auch immer nötig ist, um den Übergang sicher zu machen. Zumindest ist das meine Erfahrung. Sie können viel tiefer graben, als ich es je tun würde.
2. Abgesehen von und vielleicht getrennt von der LLM-Lösung halte ich dieses Muster technischer Schulden für nahezu unvermeidlich, zumindest mit Menschen. In einer perfekten Welt weiß jeder Mensch und jeder Reviewer genau, welche Architektur zu schreiben ist und welche Tests alle Regeln und Annahmen vermitteln, denn egal was passiert, Leute werden gehen. Ich habe diese Codebasis allerdings nie gesehen. Also sind die Regeln und Annahmen bestenfalls halb niedergeschrieben, vielleicht in einigen Kommentaren oder Dokumenten, Kommentare oder Dokumente, die die nächste Person, die diesen Teil der Codebasis bearbeitet, vielleicht sieht oder auch nicht. Und so geht es weiter.
Ich arbeite an einer Codebasis, die auf Windows, Mac, Linux, Android und iOS läuft. Diese Betriebssysteme ändern sich im Laufe der Zeit, ihre Anforderungen ändern sich, ihre APIs ändern sich, die Welt ändert sich und neue APIs werden für neue Dinge benötigt, die Menschen tun, und unsere ursprünglichen Entscheidungen für plattformübergreifende Lösungen passen nicht mehr perfekt. Wir müssen uns weiterbewegen und ausliefern, und wir können nicht einfach die Welt anhalten und neu architekturieren. Außerdem, wie der OP, nicht einmal [...]
- cebert
Wenn du jemals mit kostengünstigen Offshore-Auftragnehmern gearbeitet hast, weißt du, dass das wahr ist ...