Neues Software-Projekt? Manche Abkürzungen bringen dich schneller auf den Markt – und andere lassen dein Schiff untergehen.

Jeder sagt dir, dass du schnell Feedback sammeln sollst. Jeder sagt dir, dass weniger mehr ist. Jeder sagt dir, dass das günstigste Feature das ist, das du nicht brauchst und deswegen auch gar nicht bauen musst. Und immer wieder hörst du, dass du am Anfang auch mal „quick and dirty“ sein darfst, um deine Softwareidee schnell auf den Markt zu bringen.

Was dir fast niemand sagt: Es gibt zwei verschiedene Klassen von Abkürzungen. Beide bringen dich schnell auf den Markt, aber die eine macht dir das Leben zur Hölle, wenn es ernst wird.

Nicht alle Abkürzungen sind bösartig…

Hier sind ein paar Beispiele für Abkürzungen, die in der Regel okay sind:

1. Eine Architektur, die zwar gerade gut genug ist, aber wahrscheinlich nicht skaliert. Natürlich baust du kein riesiges Cluster, wenn deine einzige Nutzerin gerade noch deine Mutter ist. Aber wenn die Nutzerzahlen steigen, erkennst du den Bedarf an Skalierbarkeit vermutlich früh genug und kannst rechtzeitig und Schritt für Schritt dorthin migrieren.
2. Fake Doors. Wenn du wissen möchtest, ob deine Zielgruppe an einem Feature interessiert ist, baust du nicht das Feature. Stattdessen baust du z. B. erst mal nur einen Button und registrierst, wie oft er geklickt wird. Anhand dieser Daten entscheidest du dann, ob du das Feature baust oder nicht. Manche Entwickler bekommen bei dem Vorschlag einer Fake Door zwar Schnappatmung, aber meines Wissens nach ist noch niemand daran gestorben.

… manche aber schon

Und hier sind zwei Beispiele für Abkürzungen, die du nicht nehmen solltest:

1. „Analytics machen wir später.“ Wenn du nicht von Anfang an sehen kannst, wie (und ob!) dein System verwendet wird, triffst du mehr Annahmen als du müsstest. Wie viel Zeit verbringt ein Nutzer in deinem Flow? Wie oft schlägt eine Anfrage fehl? Wie oft bricht eine Nutzerin den Zahlungsvorgang ab? Das sind wichtige Fragen, die du beantworten können musst, und zwar von Anfang an – und in jedem Ökosystem gibt es Frameworks und Anbieter, die dir die schwere Arbeit abnehmen.
2. Keine historischen Daten. Wenn dein System benutzt wird, ändern sich Nutzer- und Kundendaten. Felder werden bearbeitet. Entitäten werden gelöscht. Siehst du immer nur den aktuellen Zustand, fehlen dir wichtige Informationen darüber, wie der Weg dorthin aussah. Unter Umständen geht dir dadurch wichtiges Wissen verloren, z. B. wenn du einen kritischen Fehler nachvollziehen musst oder wenn du deinen Kunden historische Auswertungen bereitstellen sollst. Du kannst Daten aufräumen und löschen, wenn du merkst, dass du sie nicht brauchst – aber es ist sehr aufwendig bis unmöglich, die Vergangenheit zu rekonstruieren.

Wie erkennst du, ob eine Abkürzung gefährlich ist oder nicht?

Wenn du beurteilen willst, ob du eine Abkürzung nehmen kannst oder nicht, kannst du dir diese drei Fragen stellen:

1. „Wie viel Zeit spare ich jetzt wirklich, wenn ich die Abkürzung nehme?“ Sprechen wir hier von wenigen Stunden oder einigen Wochen? Und wie ändert sich diese Zahl, wenn es darum geht, die Abkürzung später aufzuräumen? Ist das dann genauso schnell, wie sie jetzt einzubauen? Oder erzeugt sie während ihrer Lebenszeit zusätzlichen Aufwand für später?
2. „Wie wahrscheinlich ist es, dass mich diese Entscheidung einholt?“ Ich habe schon Code Bases gesehen, in denen „quick-and-dirty“-Hacks ihr fünf- oder sogar zehnjähriges Jubiläum gefeiert haben – teilweise auch deshalb, weil nie der Bedarf dafür entstanden ist, es „richtig“ zu bauen.
3. „Was ist das Schlimmste, was passieren kann, wenn ich die Abkürzung nehme?“ Die Bandbreite an möglichen Antworten auf diese Frage ist sehr groß: Von Randfällen, die wahrscheinlich nie eintreten werden, bis hin zu rechtlichen Konsequenzen, wenn jemand mal genau hinsieht, habe ich schon alles gesehen.

Diese und weitere Fragen sind hilfreich – doch sie leben nicht in Isolation. Faktoren wie die Art deines Produkts, der Zielmarkt und die Zielgruppe können einfache Entscheidungen sehr komplex machen oder harmlose Hacks zu bösartigen Problemen werden lassen: Was in einer B2C-Mobile-App vielleicht in Ordnung ist, ist in einem B2B-Backend mit Zahlungsverkehr vielleicht ein sehr viel größeres Risiko.

Was, wenn du diese Fragen nicht beantworten kannst?

Vielleicht wusstest du bis gerade nicht einmal, dass diese Fragen wichtig sind. Vielleicht bist du jetzt an dem Punkt, dass du nicht weißt, wie du diese Fragen beantworten sollst. Das ist gut, denn jetzt bist du einen Schritt weiter. Bis gerade wusstest du nicht, was du nicht weißt. Jetzt weißt du, was du nicht weißt.

Die spannende Frage, die du – und nur du – beantworten kannst: Habe ich das Budget, um Lehrgeld zu zahlen? Habe ich Zeit für Experimente und vertraue ich darauf, dass ich oder mein Team, schnell genug reagieren kann, wenn die Hütte doch mal Feuer fängt? Oder bediene ich mich der Erfahrung der Leute, die diese Fehler bereits gemacht haben?

In meiner täglichen Arbeit höre ich häufig Sätze wie: „Das habe ich in der Vergangenheit schon einmal gemacht und in der Regel endet das böse.“ Oder: „Wenn wir das machen, müssen wir damit rechnen, dass wir das spätestens in einem Quartal aufräumen müssen und ich weiß nicht, ob sich die Zeitersparnis jetzt lohnt.“ Und da ich inzwischen selbst seit mehr als sieben Jahren professionell Software entwickle, sage ich solche Sätze oft auch selbst.

Solche Einblicke können dir Wochen an Arbeit und Zehntausende Euro sparen – und plötzlich wirken die zwei Tage Mehraufwand wie das größte Schnäppchen des Monats.

Kannst du dir vorstellen, dass dir diese Erfahrung in deinem aktuellen Projekt helfen könnte? Dann lass uns gern mal sprechen – unverbindlich, entspannt und dann, wenn es dir passt: Termin in meinem Kalender aussuchen.