- Abhängigkeiten wirken wie kostenlose Funktionalität, bringen in der Praxis aber vielfältige Kosten und Komplexität mit sich
- Eine falsche Abhängigkeit verursacht diverse Risiken wie Lernkurve, plötzliche Interface-Änderungen sowie Probleme bei Deployment und Installation
- Als repräsentatives Beispiel verfolgt TigerBeetle aus Gründen der Sicherheit, Performance und operativen Einfachheit eine „Zero-Dependency“-Politik
- Der Autor schlägt ein Framework zur Bewertung von Abhängigkeiten (Verbreitung, Stabilität, Tiefe, Ergonomie, Vollständigkeit) vor
- Kritisches Denken, um gute von schlechten Abhängigkeiten zu unterscheiden, sowie eine vorsichtige Entscheidung unter Berücksichtigung nicht nur kurzfristiger Produktivität, sondern auch der Gesamtkosten und Risiken, sind unerlässlich
Falsche Abhängigkeiten sind kostspieliger als NIH (Not Invented Here)
Nachteile und versteckte Kosten von Abhängigkeiten
- Viele Entwickler betrachten das Hinzufügen von Abhängigkeiten als „kostenlose Funktionalität“, tatsächlich entstehen aber folgende Kosten
- Zeit- und Komplexitätsaufwand zum Erlernen
- Schon die Installation der Abhängigkeit ist oft schwierig
- Bei größeren Versions-Upgrades entsteht die Last, sogar den eigenen Code umfangreich anpassen zu müssen
- Die Abhängigkeit muss am Ende zwingend in der Deployment-/Installationsumgebung vorhanden sein (Komplexität durch Container, Bundling usw.)
- Die Einführung einer falschen Abhängigkeit kann zu einer komplizierten Deployment-Struktur ohne Bezug zur Kernfunktionalität führen
TigerBeetles Zero-Dependency-Prinzip
- TigerBeetle ist eine auf Vanilla Zig basierende Finanzdatenbank und verfolgt eine Zero-Dependency-Politik
- Die Entwicklung erfolgt ausschließlich in Zig, ohne externe Abhängigkeiten jenseits der Zig-Toolchain
- Ziel ist es, Probleme wie Supply-Chain-Angriffe, Performance-Verlust und längere Installationszeiten durch Abhängigkeiten zu vermeiden
- Je tiefer Software in der Infrastruktur verwurzelt ist, desto stärker verstärken sich die durch Abhängigkeiten entstehenden Kosten über den gesamten Stack hinweg
- Die Nutzung einer standardisierten kleinen Toolbox ist für Wartbarkeit und Entwicklungseffizienz vorteilhaft
- Mit Zig allein konzentriert man sich darauf, neue Probleme schnell anzugehen und die Komplexität zu reduzieren
Framework zur Bewertung von Abhängigkeiten
- Obwohl anerkannt wird, dass vollständige Abhängigkeitsfreiheit für alle Entwickler unrealistisch ist, wird betont, dass Abhängigkeiten sorgfältig bewertet werden müssen
- Der Autor schlägt die Bewertung von Abhängigkeiten anhand der folgenden fünf Kriterien vor
- Verbreitung (Ubiquity): Wie häufig ist sie in der Zielumgebung vorhanden? Ist separates Deployment/Installation nötig?
- Stabilität (Stability): Wie oft treten Probleme wie Abwärtskompatibilität, API-Änderungen oder eingestellte Unterstützung auf?
- Tiefe (Depth): Wie viel tatsächliche Funktionalität verbirgt sich unter der API, und wie schwer wäre es, sie selbst zu implementieren?
- Ergonomie (Ergonomics): Ist die API intuitiv/deklarativ und leicht zu verwenden, und wie steht es um die Dokumentation?
- Vollständigkeit (Watertightness): Wie gut funktioniert die Abstraktion, und wie wenig muss man sich um die zugrunde liegende Technik kümmern?
- In der Entwickler-Community wird meist nur die Ergonomie diskutiert, während die übrigen vier Punkte oft übersehen werden
Beispiele für gute Abhängigkeiten
-
POSIX-Systemaufrufe
- Allgegenwärtigkeit: Auf fast allen Plattformen wie Linux, Android, macOS und BSD verfügbar
- Stabilität: Sehr hohe Interface-Kompatibilität, kaum Veränderungen
- Tiefe: Eine einzelne API verbirgt Hunderttausende Zeilen Kernel-Code
- Ergonomie: Etwas traditioneller C-Stil, aber im praktischen Einsatz gut handhabbar
- Vollständigkeit: Meist unproblematisch, mit einigen Detailthemen wie der dauerhaften Persistenz von Daten auf Speichermedien
-
ECMA-48-Terminalsteuersequenzen
- Allgegenwärtigkeit: Mit Ausnahme von
cmd.exe unter Windows von den meisten Terminals unterstützt
- Stabilität: Seit 1991 unverändert
- Tiefe: Einen solchen Standard selbst zu schaffen wäre absurd schwierig
- Ergonomie: Abgesehen von der schwer lesbaren
Esc-Zeichenverwendung solide
- Vollständigkeit: Sehr geringe Sorge über Hardware-Abhängigkeiten
-
Webplattform (Web API, HTML, JS, CSS usw.)
- Allgegenwärtigkeit: Webbrowser sind in nahezu jeder Umgebung weltweit installiert
- Stabilität: Starke Politik der Abwärtskompatibilität
- Tiefe: Einen eigenen Browser zu entwickeln ist praktisch unrealistisch tiefgreifend
- Ergonomie: Etwas komplex, aber Dokumentation und Entwicklerwerkzeuge sind hervorragend
- Vollständigkeit: Sehr vollständig, abgesehen von Sonderfällen wie Dateien, Audio und Video
Fazit
- Statt Copy-and-Paste und übermäßigem Einsatz von Abhängigkeiten sind kritisches Denken und eine Analyse der Gesamtkosten unverzichtbar
- Bei der Einführung von Abhängigkeiten sollte man Kosten und Nutzen jeder einzelnen Abhängigkeit kritisch bewerten und auch die potenziellen Risiken und Kosten des Gesamtsystems unbedingt berücksichtigen; eine sorgfältige Auswahl ist langfristig deutlich günstiger und sicherer
2 Kommentare
TigerBeetle: Eine auf Buchhaltung spezialisierte OLTP-Datenbank
Hacker-News-Kommentare
TigerBeetle war mir als Beispiel neu, also habe ich es mir selbst angesehen. Wenn man eine Zig-basierte Finanz-Ledger-Datenbank baut, bei der Sicherheit und Performance entscheidend sind und die auf einem einzelnen CPU-Kern eine Million Transaktionen pro Sekunde verarbeiten muss, dann ist es völlig vernünftig, zusätzliche Abhängigkeiten wegen des erhöhten Risikos zu vermeiden. Aber die meisten normalen Entwickler bauen gewöhnliche CRUD-Systeme, und diese sind im Allgemeinen nicht so stark. Viele Abhängigkeiten mögen voller Bugs sein, aber oft sind sie trotzdem von höherer Qualität als das, was die meisten Entwickler selbst bauen würden. Auch Unternehmen werden in der Praxis durch das Niveau der Entwickler begrenzt, die sie einstellen können. Da jede Situation anders ist, sollte man sich merken, dass auch gegensätzliche Ratschläge in ihrem jeweiligen Kontext beide richtig sein können
Ich arbeite tatsächlich bei TigerBeetle. Der Kernpunkt ist der Kontext. TigerBeetle oder auch rust-analyzer haben eine starke Entwicklungskultur, lösen aber unterschiedliche Probleme und formen deshalb unterschiedliche Kulturen. Die im Artikel erwähnten Abhängigkeiten sind eher Systemschnittstellen als Bibliotheken, etwa POSIX, ECMA-48 oder die Web-Plattform. Bibliotheksabhängigkeiten kann man bei Problemen notfalls neu schreiben, aber grundlegende Dinge wie Systemschnittstellen sind praktisch unmöglich oder sehr teuer auszutauschen. Es ist mächtig, sich bewusst dagegen zu entscheiden, Dinge zu tun, die nicht zum Umfang der Software passen. Wenn man zum Beispiel ein Expertenteam für Matrixmultiplikationscode hat, kann man für andere Bibliotheken außerhalb des Kerngeschäfts trotzdem externe Lösungen verwenden, aber ich denke, man sollte die Verantwortungszerlegung des Produkts besser gestalten. So lassen sich unverzichtbare Abhängigkeiten im System besser isolieren
Das Problem an dieser Sichtweise ist, dass sie nur dann gilt, wenn man ausschließlich an Entwickler auf unterstem Niveau denkt. Im Tech-Bereich gibt es eine Tendenz, Ratschläge auf das niedrigste Niveau zu verwässern, aber ehrlich gesagt habe ich fast nie in Umgebungen gearbeitet, in denen Entwickler so schwach waren, dass sie eine kaputte Abhängigkeit nicht forken und das Problem lösen konnten. Es gibt auch viel Herablassung gegenüber CRUD, dabei verursachen schlechte Abstraktionen bei CRUD enorme Zeitverschwendung und Schmerzen. Selbst populäre Dinge haben oft viele Probleme und sind unproduktiv, sobald man über ein wirklich grundlegendes Tutorial-Niveau hinausgeht
Das hat nichts mit dem Niveau der Entwickler selbst zu tun. Egal welche Toolchain oder welches Produkt man verwendet, am Ende nutzt man immer Abhängigkeiten, die andere gebaut haben. Kaum jemand um mich herum implementiert Matrixmultiplikation selbst, und selbst diese Leute implementieren nicht auch noch Open-Source-Bibliotheken, die nichts mit ihnen zu tun haben. Meistens versteift man sich nur dann auf Abhängigkeiten an sich, wenn regulatorische Anforderungen, persönliches Interesse oder eine besondere Bindung an eine bestimmte Bibliothek im Spiel sind. Wenn alle dieses Prinzip vollständig anwenden würden, würden wir am Strand sitzen und nur Sand aufheben
Die Aussage „durchschnittliche CRUD-Entwickler sind nicht stark“ ist übermäßig pauschal. Die meisten Entwickler können sich die Systeme, an denen sie arbeiten, nicht aussuchen, und auch während der Entwicklungszeit fehlen ständig Ressourcen. Man muss „günstige“ Abhängigkeiten nutzen, um funktionierende Software schnell auszuliefern. Das klingt nach einer Aussage ohne echtes Verständnis dieser Realität
TigerBeetle ist ein relativ junges Startup und noch nicht einmal bei Version 1.0. Ich denke, es ist viel zu früh, um zu sagen, ob dieser Ansatz wirklich funktioniert
NIH (Not Invented Here) selbst ist sehr nützlich, wenn man es mit einer realistischen Einschätzung dafür einsetzt, wofür man Verantwortung übernehmen will. Zum Beispiel kann es sich oft lohnen, ein Web-Frontend-Framework zu bauen und zu pflegen, das exakt zur eigenen Domäne passt. Bei Datenbanken, Game-Engines, Webservern oder kryptografischen Grundfunktionen ist die Lage aber anders. Wenn die Schwierigkeit so hoch ist, dass bestehende Lösungen das Problem nicht mehr abdecken, sollte man zuerst darüber nachdenken, das Problem neu zu definieren. Ich denke, es ist viel günstiger, das Problem selbst neu zu ordnen, als die gesamte SQLite-Testsuite von Grund auf neu zu bauen
Auch bei Datenbanken, Game-Engines, Webservern und Krypto-Primitiven gibt es viele Fälle, in denen es besser ist, sie selbst zu bauen. Wenn einfache Dateien plus Laufzeitindizes genügen, ist selbst SQLite oft schon zu viel. Gerade bei kleinen Teams sind für viele Spiele Custom-Engines oft vorteilhafter. Der Hauptvorteil fertiger Engines ist die Pipeline, aber dafür zahlt man mit großem Overhead. Webserver unterscheiden sich in der Komplexität nicht von FastCGI-Apps. Und auch Krypto ist nicht in jeder Situation ein Sicherheitsproblem; einfache Hash-Prüfungen kann man durchaus selbst implementieren. Es ist nicht gut, bei schwierig wirkenden Themen eine erlernte Hilflosigkeit zu entwickeln. Wichtig ist auch, dass eine bestehende Lösung ein Problem zwar lösen kann, aber deshalb noch lange nicht optimal oder am effizientesten ist
Warum gibt es dann so viele Datenbank-Engines? Letztlich haben komplexe Computersysteme jeweils eigene Trade-offs. Randbedingungen, Skalierbarkeit, Nebenläufigkeit, Sicherheit, Dateneigenschaften, Speicherverfahren und mehr bieten sehr viele Wahlmöglichkeiten. Ich finde: Je höher die Kosten einer Abhängigkeit sind, desto mehr vertraue ich ihr, wenn sie selbst versucht, weitere Abhängigkeiten zu minimieren. Automatisierte Dependency-Management-Systeme machen Probleme oft eher komplexer, daher halte ich sorgfältige manuelle Verwaltung für entlastender
Ich denke, es gibt zwei Gründe, Drittanbieter-Abhängigkeiten zu verwenden. (1) Der Dienstanbieter veröffentlicht sie selbst und ihre Lebensdauer ist relativ deckungsgleich. (2) Sie ersetzen komplexen Code, den ich nicht selbst schreiben möchte. Bei (1) ist das aus geschäftlichen Gründen unproblematisch. Man muss dann nur akzeptieren, dass Updates des Dienstes größere Änderungen mit sich bringen können. Der Wert von (2) hängt davon ab, wie komplex der Code ist, den ich vermeiden will. Eine Abhängigkeit einzuführen bedeutet, Zeit und Ressourcen für Updates und Tests nach dem Zeitplan anderer aufzuwenden und diese Verantwortung mitzutragen
Man stößt schnell auf Probleme, die sich mit einem RDBMS nicht lösen lassen. RDBMS sind auf gleichzeitige Datenänderungen und variable Datensätze ausgerichtet; wenn man das nicht braucht, kann schon ein einfacher Index enorme Performancegewinne bringen. Wenn die Daten unveränderlich sind, lässt sich eine eigene Implementierung bauen, die gegenüber einem RDBMS viel schneller ist
Das Beispiel mit dem RDBMS ist interessant. In der Wikipedia gibt es mehr als 100 RDBMS, und jedes davon hat Probleme, die es lösen kann, und solche, die es nicht lösen kann. Das ist das Ergebnis praktischer Überlegungen und tatsächlicher Umsetzung
Abhängigkeiten erzeugen Risiken, aber ganz ohne sie kann man bei Entwicklung und Time-to-Market zurückfallen. Deshalb ist ein Prozess für das Dependency-Management wichtig
Punkt 4 und 5 sind wirklich wichtig, werden aber oft vergessen. Selbst in persönlichen Projekten erlebt man nach längerer Pause bei der Rückkehr, dass Abhängigkeiten veraltet sind oder ein Repo gelöscht wurde. Deshalb forke ich heute den Quellcode selbst privat, baue ihn direkt und forke auch die Abhängigkeiten der Abhängigkeiten auf Quellcodeebene. So lässt sich der Schaden minimieren, wenn sich das Ökosystem später abrupt verändert. Deshalb bevorzuge ich Quellbibliotheken gegenüber Binärbibliotheken
Bei Punkt 5 kann ein Fork zu belastend sein. Vendoring, also das Ablegen der Abhängigkeiten in einem eigenen Git oder Cache-Proxy, ist ebenfalls eine gute Methode. Besonders für langlebige Projekte passt das gut. Wenn es wie bei NodeJS sehr viele Abhängigkeitsdateien gibt, sind Tools wie Yarn oder PNPM oft effizienter
Im Zusammenhang mit Punkt 4: Eine bekannte Abhängigkeit wie SQLite wird mit hoher Wahrscheinlichkeit viel länger bestehen als das Produkt, das ich baue. Wenn ich glaube, mein Produkt werde länger leben als dieses Open-Source-Projekt, ist das eher vermessen. Den Linux-Kernel würde ich auch nicht selbst bauen wollen
Jeder Code sollte sich zumindest ohne Netzwerkverbindung bauen lassen. Am besten ohne Binärartefakte, auch wenn das nicht immer realistisch möglich ist
Das ist ein hervorragender Gedanke. Ich werde das in mein Verfahrensdokument zur Einführung von Abhängigkeiten aufnehmen. Das Problem ist, wenn der Dependency-Tree wie bei JavaScript zu tief wird
Nach langer Erfahrung ist am Ende alles nur „It Depends™“. Als ich jünger war, habe ich mich an Prinzipien ohne Ausnahmen festgebissen und dadurch manchmal den schlechtesten Code produziert, weil ich ungeeignete Bibliotheken oder Paradigmen mit Gewalt angewendet habe. Heute packe ich Dinge, die ich oft benutze, in eigene Bibliotheken und veröffentliche sie als Pakete, und nur das, was ich selbst nicht leisten kann, decke ich mit externen Abhängigkeiten ab. Wenn Qualität und Wartbarkeit für mich akzeptabel sind, nehme ich auch externe Dinge gern an
In der Energiebranche gibt es die Tendenz, Abhängigkeiten bewusst zu vermeiden. Führt man externe Abhängigkeiten ein, muss man alle Änderungen daran nachverfolgen. AI-Coding-Tools waren dabei eine große Hilfe und werden vor allem für die Erstellung von CLI-Tools genutzt. Auch OpenAPI-Dokumente werden mithilfe von LLMs erzeugt und dann über die Go-Standardbibliothek bereitgestellt. Das LLM selbst ist zwar eine externe Abhängigkeit, aber die damit erzeugten CLI-Tools haben nichts mit dem eigentlichen Code zu tun, daher sind die Qualitätsanforderungen geringer. Natürlich wollen Frontend-Entwickler nicht ohne React arbeiten, aber solche Produkte behandeln wir als Sonderfall außerhalb. Wenn man Ingenieuren kleine Hilfsmittel gibt, die ihre Qualitätsfixierung auf Abhängigkeiten verringern, lässt sich eine Politik zur Minimierung von Abhängigkeiten leichter durchsetzen
Die Fähigkeit, gute von schlechten Abhängigkeiten zu unterscheiden, ist eine wichtige Kompetenz. Meiner Ansicht nach sind kostenpflichtige Abhängigkeiten meist nachteilig. Die anbietende Firma hat sie wahrscheinlich so entworfen, dass sie Lock-in fördert. „Dependency-Minimalismus“ ist ein gutes Konzept (relevanter Tweet von VitalikButerin)
Kostenpflichtige Abhängigkeiten haben nur eine einzige Support-Quelle. Wenn die anbietende Firma schließt, ist das ganze Projekt gefährdet. Die meisten Unternehmen existieren nicht ewig, daher sollte man unbedingt prüfen, ob die Zukunft einer Abhängigkeit die Flugbahn des eigenen Projekts beeinflusst
Ich habe schlechte Erfahrungen mit kostenpflichtigen Abhängigkeiten gemacht, die von Teams ohne technischen Hintergrund erzwungen wurden. Andererseits sind in der Community breit genutzte „Open-Core“-Abhängigkeiten wie Sidekiq viel vertrauenswürdiger, weil sie weit weniger wahrscheinlich plötzlich verschwinden. Der Vorteil kostenpflichtiger Lösungen ist, dass man sich um Support weniger Sorgen machen muss, solange das Unternehmen solide betrieben wird
Sowohl kostenpflichtige als auch kostenlose Komponenten eines Unternehmens bringen Vendor Lock-in mit sich. Das Risikomanagement ist Aufgabe des Integrationsteams; es muss Alternativen suchen oder modularisieren, um das Risiko zu steuern
Wenn etwas kostenpflichtig ist, sollte es unbedingt über Schnittstellen geliefert werden, die auf offenen Standards oder austauschbaren Implementierungen beruhen, damit Lock-in vermieden wird. Wenn es andere Optionen gibt, bleibt die Möglichkeit zum Wechsel erhalten
Dass kostenpflichtige Abhängigkeiten schlecht seien, kann auch ein Signal sein, dass möglicherweise zu wenig Geld vorhanden ist. Ich möchte, dass der Support für meinen Code jemandes „Job“ ist. Wenn es viele Unterstützer oder viele Entwickler gibt, die freiwillig Verantwortung übernehmen, ist das stabilisierend; und selbst bei einem persönlichen Projekt braucht man jemanden, der einen im Problemfall unterstützt, auch wenn der Quellcode offen ist. Entscheidend ist ein Verantwortungsgefühl, das das Projekt nicht einfach verwaisen lässt, selbst wenn das Unternehmen aussteigt
Viele Menschen sind davon besessen, neuen Code zu schreiben, aber in Wirklichkeit ist es in neun von zehn Fällen deutlich effizienter, selbst eine miserable Abhängigkeit zu verwenden
Abhängigkeiten sind ein zweischneidiges Schwert. In großen Softwarekonzernen ist es oft billiger, die Pflege von Code aufzugeben und neu zu schreiben, deshalb tun sie das auch. In kleinen Web- oder Branding-Agenturen braucht man faktisch kein hochwertiges Backend. Aber die gefürchteten Enterprise-Patterns sind auch deshalb entstanden, damit Code noch in fünf Jahren isoliert und wartbar bleibt, selbst wenn Dokumentation und Branchenwissen verschwunden sind und ohne externe Abhängigkeiten auskommen muss. Externe Abhängigkeiten bergen zwei Risiken: eingestellter Support oder zerstörerische Änderungen. Am Ende wirkt sich das auf den Fluss der Feature-Entwicklung aus. Bei internen Komponenten kann man diese Trade-offs intern kontrollieren. Für SaaS ist es richtig, aus kurzfristigen Erfolgsgründen schnell Abhängigkeiten einzusetzen, aber wenn Sicherheit und langfristiger Support Pflicht sind, gewinnt man nur mit einer langfristigen Perspektive. Das Schreiben neuen Codes ist fast nie der Flaschenhals einer Organisation
Mich würde interessieren, wie ernst Unternehmen Sicherheitslücken und Lizenzen handhaben. Früher war ich bei Abhängigkeiten großzügig, aber nachdem ich zu einer Firma gewechselt bin, die bei Sicherheit und Lizenzen streng ist, hat sich mein Blickwinkel massiv verändert
Der Unterschied zwischen Bibliotheken und Frameworks ist ebenfalls wichtig. Eine Bibliothek ist ein Tool, das eine Sache gut macht, während ein Framework die gesamte Struktur einer App vorgibt. Die Go-Community hält Abstand zu großen Frameworks und bevorzugt die Standardbibliothek, leichte Bibliotheken und bei Bedarf auch schlichtes Copy-and-paste des Quellcodes. Frameworks wie Gin (Web-API) oder GORM (ORM) sind zwar bequem, schränken aber die interne Struktur ein und erhöhen die Komplexität. Weil das Standard-SDK von Go selbst schon ziemlich stark ist, halte ich es für richtig, nicht mehr Abhängigkeiten hinzuzufügen als nötig
Der Autor stammt aus Neuseeland. Dahinter steckt der neuseeländische Geist des Number 8 wire, also die Haltung, mit dem Vorhandenen und etwas handwerklichem Geschick irgendwie eine Lösung zu finden (Wikipedia-Artikel zu Number 8 wire)
Auch erfahrene Entwickler aus anderen Ländern als Neuseeland stimmen dem oft ähnlich zu. Fast jeder hat schon unter einer falschen Abhängigkeitswahl oder unnötigen Bibliotheks-Upgrades gelitten
Als jemand aus Neuseeland fühlt es sich für mich so an, als sei die Number-8-Wire-Mentalität schon vor 20 Jahren verschwunden
Das habe ich heute zum ersten Mal gelernt. Es erinnert mich an die australische Redewendung „She'll buff out, mate“
Größe und Kommerzialisierungsgrad einer Abhängigkeit wirken sich auch auf ihre Skalierbarkeit aus. Wenn ein Tool in Umgebungen eingesetzt wird, die 100- bis 1000-mal größer sind als meine, ist die Wahrscheinlichkeit geringer, dass es bei meinen Problemen an Grenzen stößt. Auf diesem Größeniveau werden Bugs oft früher entdeckt oder behoben, und dadurch läuft es für mich am Ende sicherer
Es gibt auch große Bibliotheken, die in kleinen Umgebungen überhaupt nicht funktionieren. Zum Beispiel ist der Swift-Protocol-Buffer-Compiler früher bei unerwarteten Feldern abgestürzt. Viele große Unternehmen testen diese Pfade jenseits ihres eigentlichen Großmaßstabs gar nicht selbst
Ich habe schon in bekannten Bibliotheken von großen Firmen wie Meta, Google oder Microsoft gravierende Bugs gefunden. Selbst wenn man Issues meldet, dauert es oft lange, bis sie behoben werden, und der Widerstand gegen Änderungen ist groß. In solchen Situationen war eine Eigenimplementierung am Ende sogar schneller und leistungsfähiger. Besonders im Consulting wird die Richtung der Arbeit oft durch unvernünftige Kundenanforderungen hin- und hergeworfen. Je größer mein Vertrauen darin wird, dass ich Dinge selbst umsetzen kann, desto öfter ist meine eigene Implementierung besser als eine riesige externe Abhängigkeit. Natürlich baue ich keine wirklich gigantischen Dinge wie Browser oder AI-Modelle, aber etwa eine lokale Inference-Engine, einen HTML-Renderer oder eine selbst geschriebene Graphdatenbank schon. Auftraggeber erwarten nicht Neues um der Innovation willen, sondern geringeres Risiko. Wenn ich selbst entwickle, kann ich Deadlines viel leichter einhalten. Effizienter als Zeit mit der Dokumentation von Google oder anderen Tech-Giganten zu verbringen, ist es oft, es einfach selbst zu bauen. In den letzten drei Monaten habe ich mit 12-Stunden-Tagen bis spät in die Nacht darüber viel nachgedacht, während ich versucht habe, ein von einem früheren Team vernachlässigtes Projekt zu retten