// HEISE ONLINE — SALUTE
Werkzeugwahl, Teil 2: Der Stack steht, bevor das Problem klar ist
Viele Teams legen ihre Datenbank fest, bevor sie das Problem kennen. Das Produkt ist dabei selten der Fehler, die falsche Werkzeugkategorie dagegen sehr oft.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Im ersten Teil dieser Serie ging es um die Frage, welche Programmiersprache ein Team einsetzen sollte, wenn Agenten den Code schreiben. Meine Antwort war, dass die Sprache an Gewicht verliert: Entscheidend ist nicht mehr, was sich angenehm schreiben lässt, sondern was sich deterministisch prüfen lässt. Am Ende blieb allerdings eine Frage offen, die sich mit diesem Argument nicht erledigt, nämlich die nach der Art des Werkzeugs.
Wie diese Frage in vielen Projekten beantwortet wird, zeigt eine Szene, die mir in unterschiedlichen Varianten immer wieder begegnet. Ein Projekt startet, das erste fachliche Gespräch hat noch nicht stattgefunden, aber der Stack steht bereits fest: diese Sprache im Frontend, jene im Backend, und die Datenbank ist „bei uns eben PostgreSQL“. In anderen Häusern heißt sie Microsoft SQL Server oder MongoDB, aber das Muster ist dasselbe. Niemand hat gefragt, was das Produkt eigentlich speichern soll, und trotzdem ist die Antwort schon gegeben.
In dieser Szene werden zwei Entscheidungen vermengt, die sehr unterschiedliches Gewicht haben. Die erste betrifft das Produkt innerhalb einer Kategorie: Ob ein Team PostgreSQL oder eine andere relationale Datenbank einsetzt, ist in den meisten Fällen eine Frage von Gewohnheit, Lizenz und vorhandenem Wissen. Das ist das Gegenstück zur Sprachwahl aus dem ersten Teil, und für das Ergebnis ist es ähnlich selten entscheidend.
Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.
Die zweite Entscheidung betrifft die Kategorie selbst. Ob Daten in eine relationale oder in eine dokumentenbasierte Datenbank gehören, ob Dateien in einem Objektspeicher liegen sollten oder ob zwei Systeme über eine Message-Queue miteinander sprechen, ist keine Geschmacksfrage. Es ist eine Architekturentscheidung, weil sie bestimmt, welche Probleme ein System von Haus aus löst und welche das Team selbst lösen muss.
Ein fester Stack trifft diese zweite Entscheidung, bevor irgendjemand die Anforderungen kennt. Er legt nicht nur fest, welches Produkt eingesetzt wird, sondern auch, welche Kategorien überhaupt infrage kommen. Was nicht im Stack steht, wird gar nicht erst erwogen, und zwar nicht, weil jemand es abgewogen und verworfen hätte, sondern weil niemand auf die Idee kommt, danach zu fragen.
Bemerkenswert ist dabei, wie ungleich die Aufmerksamkeit verteilt ist. Über Produkte, Datenbanken, Frameworks und Sprachen streiten Teams oft mit großer Leidenschaft. Die Frage nach der Kategorie, die für das Ergebnis viel schwerer wiegt, kommt in diesen Debatten dagegen kaum vor. Es wird viel über Technologie gesprochen und wenig darüber, welches fachliche Problem sie eigentlich lösen soll.
Wie teuer das werden kann, zeigt sich selten am ersten Tag. Es zeigt sich dort, wo ein Team mit großem Aufwand etwas nachbaut, das eine andere Kategorie von Haus aus mitbringt. Zwei Beispiele dafür begegnen mir besonders häufig.