Die Kosten des Wandels
Jede Technologieentscheidung ist eine Wette auf die Zukunft. Manche Wetten altern gut — semantisches HTML, Progressive Enhancement, klare Trennung der Zuständigkeiten. Andere nicht — frameworkspezifische Muster, die einen einsperren, Build-Tools, die aufgegeben werden, Abstraktionen, die Probleme lösen, die man nie wirklich hatte.
Die Kosten einer schlechten Wahl bestehen nicht nur in der Migration. Es ist die angesammelte Reibung, wenn man gegen seine Werkzeuge arbeitet statt mit ihnen. Es ist die Dokumentation, die nicht zur eingesetzten Version passt. Es ist der mentale Aufwand, Muster zu pflegen, die vor drei Jahren sinnvoll waren, es aber nicht mehr sind.
Was gut altert
Nach meiner Erfahrung teilen die Dinge, die gut altern, gemeinsame Eigenschaften:
- Sie sind langweilig. Langweilige Technologien sind langweilig, weil sie erprobt sind. Die Fehler sind bekannt. Die Grenzfälle sind dokumentiert. Die Community hat Antworten.
- Sie sind einfach. Nicht leicht — einfach. Sie haben eine kleine Angriffsfläche. Sie tun eine Sache und tun sie gut. Sie lassen sich mit anderen Werkzeugen kombinieren, statt der ganze Stack sein zu wollen.
- Sie respektieren Standards. HTML, CSS, HTTP, URLs — das sind die tragenden Wände des Webs. Direkt auf ihnen zu bauen, statt sie wegzuabstrahieren, bringt in der Regel Systeme hervor, die Bestand haben.
- Sie sind explizit. Magie macht Spaß, bis man sie debuggen muss. Expliziter Code, offensichtlicher Datenfluss und vorhersehbares Verhalten sind mehr wert als clevere Abstraktionen, die ein paar Tastenanschläge sparen.
Einfachheit verzinst sich
Ein einfaches System, das man vollständig versteht, ist wertvoller als ein ausgefeiltes System, das man nur teilweise versteht. Das gilt auf jeder Ebene — von der einzelnen Funktion bis zur gesamten Architektur.
Einfachheit heißt nicht, weniger Code zu schreiben. Sie heißt, Code zu schreiben, in dem jede Zeile aus einem Grund existiert, den man benennen kann. Sie heißt, den Ansatz mit den wenigsten beweglichen Teilen zu wählen, der das Problem noch löst. Sie heißt, dem Drang zu widerstehen, für hypothetische zukünftige Anforderungen zu optimieren.
Der Lohn dieser Disziplin verzinst sich. Einfache Systeme lassen sich leichter erweitern, leichter debuggen, leichter übergeben und unter Druck leichter durchdenken. Sie altern besser, weil weniger schiefgehen kann.
Die Praxis
Bauen für Langlebigkeit ist eine Praxis, keine Checkliste. Es bedeutet innezuhalten, bevor man eine Abhängigkeit hinzufügt. Es bedeutet zu fragen, ob die Abstraktion die Indirektion wert ist. Es bedeutet, Lesbarkeit über Cleverness zu stellen und Stabilität über Neuheit.
Es ist nicht der aufregendste Ansatz. Aber es ist der, der einem erlaubt, die Zeit mit der Arbeit zu verbringen, die zählt — statt gegen die eigenen Werkzeuge zu kämpfen.