Jede Codezeile wird zu etwas, das später verstanden, getestet, abgesichert, migriert und erklärt werden muss. Thinking-first Engineering ist nicht langsamer – es verhindert, dass Sie die falsche Belastung schneller aufbauen.

Kürzlich haben wir mit einem umsatzstarken Shopify-Händler gearbeitet, der überzeugt war, eine individuell entwickelte Loyalty-Engine für seine komplexe Tier-1-Kundenlogik zu brauchen. Sein internes Team hatte bereits ein 40-seitiges technisches Anforderungsdokument für eine maßgeschneiderte private App verfasst. Nach drei Tagen Architekturprüfung haben wir den gesamten Plan verworfen und eine Headless-Integration mit einem bestehenden Enterprise-Tool umgesetzt, ergänzt um einige gezielte Liquid-Snippets.

Indem wir darauf verzichtet haben, über 5.000 Zeilen individuellen Ruby-Code zu schreiben, haben wir dem Händler 50.000 € an Entwicklungskosten im Voraus gespart und rund 15 Stunden monatlichen Wartungsaufwand eliminiert. Der Händler brauchte nicht mehr Code, sondern eine Lösung. Das ist der Kern von Thinking-first Engineering: zu erkennen, dass Code kein Vermögenswert ist, sondern eine Belastung, die gerechtfertigt werden muss.

Der hohe Preis des „Shipping Velocity“-Irrglaubens

Viele technische Führungskräfte stecken derzeit in einem Kreislauf fest, in dem sie Produktivität an geschlossenen JIRA-Tickets oder gepushten GitHub-Commits messen. Das ist eine gefährliche Kennzahl, weil sie das Erzeugen von Artefakten statt das Lösen von Problemen belohnt. In einem modernen Stack vergrößert jede neue Funktion die Angriffsfläche für Sicherheitslücken, Performance-Einbußen und technische Schulden.

Wenn ein Team stolz darauf ist, schnell zu liefern, ohne vorher nachzudenken, beschleunigt es im Grunde auf eine Klippe zu. Ein 20-köpfiges Engineering-Team kann leicht 40 % seiner Sprint-Zyklen allein damit verbringen, die Nebenwirkungen früherer Funktionen zu bewältigen, die nie hätten gebaut werden sollen. Am häufigsten sehen wir das im E-Commerce, wo ein „Quick Fix“ für einen Sonderfall im Checkout sechs Monate später die Datenpipeline der gesamten Analytics-Suite lahmlegt.

Code erfordert Tests, Dokumentation und mentale Energie von jedem neuen Teammitglied. Wenn Sie ein Problem lösen können, indem Sie einen Geschäftsprozess ändern oder eine native Plattformfunktion nutzen, haben Sie gewonnen. Die eleganteste Lösung ist die, die null Zeilen Wartung erfordert.

Thinking-first: Anforderungen wie ein Staatsanwalt prüfen

Bei DATATIP behandeln wir jede neue Feature-Anfrage, als stünde sie vor Gericht. Bevor wir eine IDE öffnen, übernehmen wir die Rolle der Anklage und nehmen die Notwendigkeit des Codes ins Kreuzverhör. Es geht nicht um bürokratisches Ausbremsen, sondern um taktische Reibung, die aufgeblähte Architekturen verhindern soll.

Wir nutzen ein einfaches Framework, um zu prüfen, ob eine Entwicklung notwendig ist. Zuerst wenden wir den Radiergummi-Test an: Können wir dieses Problem lösen, indem wir eine Funktion entfernen oder die Oberfläche vereinfachen? Oft ist ein langsamer Checkout kein Datenbankproblem, sondern ein Problem mit „zu vielen Formularfeldern“. Zweitens verlangen wir ein RFC-Lite (Request for Comments). Wenn ein Entwickler die Logik und die Zielkonflikte nicht auf einer einzigen Seite in einfacher Sprache erklären kann, ist er noch nicht bereit, den Code zu schreiben.

„Die Kosten für das Erzeugen von Code sind dank KI auf nahezu null gesunken, doch die Kosten für die Wartung dieses Codes sind so hoch wie eh und je. Wenn Sie KI nutzen, um schneller mehr Code zu schreiben, häufen Sie einfach Schulden zu einem höheren Zinssatz an.“

KI zur Validierung nutzen, nicht nur zur Generierung

Mit dem Aufstieg von LLMs und Tools wie Cursor ist die Einstiegshürde für das Ausliefern von Code verschwunden. Das hat zu einer Flut mittelmäßiger, KI-generierter PRs geführt, die akute Symptome beheben und dabei die Gesundheit des Gesamtsystems ignorieren. Wir sind überzeugt, dass der eigentliche Wert von KI im Jahr 2024 darin liegt, Logik einem Stresstest zu unterziehen, statt Syntax zu generieren.

Statt eine KI zu bitten, „eine individuelle Middleware zu bauen“, nutzen wir sie, um Sonderfälle in unseren Architekturplänen aufzuspüren. Wir lassen sie simulieren, wie ein neues Datenschema unter zehnfacher Last scheitern könnte, oder bitten sie um drei Wege, ein Geschäftsziel ausschließlich mit nativen Shopify-APIs zu erreichen. Damit wandelt sich die Rolle des Entwicklers vom Erbauer zum Kurator und Risikomanager. Sie sind der Pilot, die KI ist das Triebwerk. Ein schnelleres Triebwerk lässt Sie nur schneller vom Kurs abkommen, wenn Sie das Ziel nicht festgelegt haben.

Der Zielkonflikt: Radikale Ehrlichkeit vs. Feature-Wünsche

Diese Denkweise erfordert einen kulturellen Wandel, in dem „Nein“ ein gültiges und respektiertes Engineering-Ergebnis ist. Das bedeutet, einem Stakeholder zu sagen, dass das gewünschte individuelle Dashboard die Website tatsächlich verlangsamen und keine verwertbaren Daten liefern wird. Es geht darum, langfristige Systemstabilität über den kurzfristigen Dopaminkick eines neuen Releases zu stellen.

Dieser Ansatz ist im Vorstand nicht immer beliebt, aber er ist der einzige Weg, leistungsstarke Software zu bauen, die skaliert. Wenn Sie aufhören, Masse zu belohnen, erkennen Sie die Brillanz der Entwickler, die Low-Code-Abkürzungen finden, mit denen das System schlank und das Unternehmen agil bleibt.

Die wichtigsten Erkenntnisse

• Code ist eine Belastung: Jede hinzugefügte Codezeile erhöht Wartungskosten und Risiko dauerhaft.
• Ergebnisse priorisieren: Messen Sie den Erfolg im Engineering an der Komplexität, die aus einem System entfernt wurde, nicht an hinzugefügten Funktionen.
• Der Radiergummi-Test: Fragen Sie immer, ob sich das Problem durch das Löschen von etwas lösen lässt, bevor Sie vorschlagen, etwas Neues zu bauen.
• KI als Berater: Nutzen Sie LLMs, um Schwachstellen in Ihrer Logik und Architektur zu finden, statt nur Boilerplate zu generieren.

---

Häufig gestellte Fragen

Schadet es meiner Karriere als Entwickler nicht, weniger Code zu schreiben?

Nein, das Gegenteil ist der Fall. Senior- und Staff-Rollen zeichnen sich durch Systemdesign und Entscheidungsfindung aus, nicht durch Tippgeschwindigkeit. Zu zeigen, dass Sie einem Unternehmen mit einer einfacheren Alternative sechs Monate Wartung erspart haben, ist ein viel stärkeres Karrieresignal als zehn mittelmäßige Features auszuliefern.

Wie widerspreche ich Stakeholdern, die mehr Funktionen wollen?

Argumentieren Sie mit Kosten und Risiken. Erklären Sie, dass jede neue Funktion die Angriffsfläche für Bugs vergrößert und die künftige Entwicklung verlangsamt. Zeigen Sie mit Daten, wie wenig bestehende Funktionen genutzt werden, bevor Sie dem Stapel neue hinzufügen.

Heißt das, wir sollten nie individuelle Software entwickeln?

Keineswegs. Individuelle Software ist für Ihr einzigartiges Wertversprechen gedacht – für das, was Ihr Unternehmen von anderen unterscheidet. Wenn ein Drittanbieter-Tool oder eine native Plattformfunktion die Aufgabe zu 80 % so gut erledigen kann, nutzen Sie es. Heben Sie sich Ihren individuellen Code für die 20 % auf, die tatsächlich Ihren Wettbewerbsvorteil ausmachen.

Die wertvollste Fähigkeit im modernen Engineering ist nicht zu wissen, wie man etwas baut, sondern zu wissen, was es wert ist, gebaut zu werden.

Nächster Schritt

Nutzen Sie diesen Beitrag als Artikel zur Engineering-Philosophie von DataTip. Sprechen Sie mit DataTip.