Wie man einen Tech-Stack auswählt, der lange hält

Drei verschiedene Dinge heißen Stack

Fällt das Wort in einer Runde, ist selten klar, welche Ebene gemeint ist. Das kostet Zeit, weil zwei Leute über verschiedene Sachen sprechen und beide recht haben. Auseinanderhalten lassen sich die Ebenen in einem Satz.

• Die Werkzeuge, mit denen ein Team arbeitet, vom Aufgabenboard bis zum Chat
• Die Technik, aus der euer Produkt besteht, von der Oberfläche bis zur Datenbank
• Die Regeln eures Geschäfts, die unter beidem liegen

Die ersten beiden wechseln, und das ist normal. Ein Werkzeug fliegt raus, sobald ein besseres kommt, und eine Oberfläche wird irgendwann neu gebaut. Beides ist kein Drama, solange es geplant passiert.

Die dritte Ebene bleibt. Was in eurem Geschäft gilt, gilt weiter, egal in welcher Sprache es später läuft. Unter der Technikwahl liegt damit eine Entscheidung, die länger trägt als jedes Framework. Wer sie überspringt, redet über Werkzeuge und meint das Produkt.

Das erste Kriterium ist der Arbeitsmarkt, nicht die Technik

Im Frontend, also in der Oberfläche, die eure Leute sehen und bedienen, stehen mehrere verbreitete Bausteine nebeneinander. Sie nehmen sich im Aufwand fast nichts. Wer behauptet, mit einem davon sei ein Produkt halb so schnell fertig, verkauft eine Vorliebe als Argument.

Was sie wirklich unterscheidet, steht in keinem Handbuch. Entscheidend ist, was in eurem Umfeld verbreitet ist und wofür ihr später Leute findet. Wer eine Stelle besetzen muss, merkt das als Erster.

Im Backend, also in dem Teil, der die Regeln durchsetzt und die Daten hält, gilt dasselbe. Verbreitete Technik und eine gängige Datenbank sind mehr wert als die seltenere, die auf dem Papier besser aussieht. Für das Verbreitete findet ihr überall jemanden. Für das Seltene findet ihr den, der es eingebaut hat.

Die Frage an ein Angebot lautet deshalb nicht, welche Technik die beste ist. Sie lautet, wer außer dem Anbieter damit noch arbeiten kann. Wer darauf keine Antwort gibt, hat eine Abhängigkeit eingeplant.

Den Aufwand treiben die Übergänge, nicht die Sprache

Ein Produkt steht selten allein. Es zieht Kundendaten aus einem anderen System, meldet Zahlungen an einen Anbieter weiter und schickt Rechnungen in die Buchhaltung. Jeder dieser Übergänge ist eigene Arbeit, und zwar jedes Mal von vorn.

Bei uns ist eine Anbindung an ein Fremdsystem im Festpreis enthalten, jede weitere kostet 1.500 Euro. Die Wahl des Frameworks bewegt diesen Betrag nicht. Die Zahl der Übergänge bewegt ihn sofort.

Ein Übergang ist jede Stelle, an der eure Anwendung etwas abgibt oder entgegennimmt. Nach außen sind das fremde Systeme, nach innen die Grenzen zwischen den Bereichen eures Geschäfts. An diesen Stellen entstehen Absprachen, Sonderfälle und Fehler, die niemand vorher gesehen hat.

Wer die Summe vorher wissen will, zählt also die Übergänge und nicht die Technologien. Genau deshalb lässt sich das ganze Projekt zum festen Umfang überhaupt rechnen. Der Umfang steht fest, sobald klar ist, was mit was reden muss.

Eigentum ist ein Auswahlkriterium, kein Schlusssatz

Die dritte Frage stellt kaum jemand, und sie ist die teuerste. Wem gehört am Ende, was da entsteht? Bei uns liegt der Quellcode ab dem ersten Tag in eurem Repository, zusammen mit den Modellen, aus denen er entstanden ist.

Das ist keine Nettigkeit, sondern eine Eigenschaft der Auswahl. Ein Produkt aus lesbarem Standard ohne versteckte Abhängigkeit läuft bei jedem Anbieter, und jedes Team, das die Sprache kann, arbeitet damit weiter. Ein Produkt, das nur bei einem Anbieter läuft, gehört euch nur auf dem Papier.

In Angeboten steht das selten von allein. Fragt danach, bevor ihr über Technik redet. Wo liegt der Quellcode am ersten Tag, und wer kann damit ohne den Anbieter weiterarbeiten?

Jedes zusätzliche Teil ist eine Entscheidung, die jemand pflegen muss

Ein Stack wächst, wenn niemand ihn verteidigt. Für jedes Problem gibt es ein fertiges Paket, und jedes davon spart am Tag des Einbaus ein paar Stunden. Bezahlt wird später, und zwar von jemand anderem als dem, der es eingebaut hat.

Zwei Fragen halten die Liste kurz. Tut ein Baustein wirklich, was er verspricht, und zwar in eurer Umgebung statt im Beispiel des Herstellers? Und pflegt ihn überhaupt noch jemand?

Wir haben beides selbst erlebt und Bausteine wieder ausgebaut, die wir vorher eingebaut hatten. Ein Baustein, den niemand mehr pflegt, ist eine Schuld ab dem Tag, an dem er hereinkommt.

Was eine solche Entscheidung kostet, zahlt ihr nicht einmal, sondern bei jeder Änderung. Deshalb ist die kürzeste Liste die beste. Was nicht drin ist, kann auch nicht brechen.

Am Ende bleiben drei Fragen, und keine davon verlangt, dass ihr die technische Debatte selbst führt. Wen findet ihr dafür, woran hängt der Aufwand, und was gehört danach euch. Wer diese Antworten gibt, ohne dass ihr nachfragen müsst, hat den Stack nicht nach Vorliebe ausgewählt.