Von Norman Schütt, Unf*ck IT | Pragmatische Modernisierung und Digitalisierung | Fractional CTO und Software Engineer für den Mittelstand
Die Blackbox
Du weißt, dass irgendwas besser laufen könnte. Vielleicht ist es die Zettelwirtschaft in der Produktion, vielleicht das Wissen, das nur im Kopf von Klaus steckt, der nächstes Jahr in Rente geht. Oder die Excel-Tabelle, die längst an ihre Grenzen gestoßen ist.
Aber sobald du „Software“ sagst, wird ein Monster geweckt. Plötzlich sitzt du in Meetings mit Leuten, die Rollen haben, die du nicht verstehst. Die Begriffe benutzen, die du nicht kennst. Die Entscheidungen von dir verlangen, deren Konsequenzen du nicht einschätzen kannst.
Du weißt nicht, welche Fragen gestellt werden, und du weißt nicht, was da drin passiert. Du weißt nur: Es dauert, es kostet, und am Ende kannst du nicht beurteilen, ob das, was du bekommst, das wert war. Das ist die Blackbox. Und sie macht Angst.
Wovor wir wirklich Angst haben
Die Blackbox erzeugt ein Gefühl, und wenn wir ehrlich sind, ist es nicht nur Verwirrung – es ist Angst.
Kontrollverlust. Nicht zu wissen, was passiert, keinen Plan zu haben, überfordert zu sein von einer Welt, deren Regeln man nicht kennt – und trotzdem Entscheidungen treffen zu müssen.
Vertrauensprobleme. Die Angst, den falschen Dienstleister zu wählen, schöne Präsentationen zu kaufen, hinter denen Dienst nach Vorschrift steckt, und am Ende Leute zu bezahlen, die das eigentliche Problem nicht verstehen.
Existenzielle Unsicherheit. Was, wenn die Kosten explodieren? Was, wenn der ROI nie eintritt? Was, wenn wir am Ende dastehen mit einer Lösung, die niemand benutzt?
Das sind keine irrationalen Ängste – sie basieren auf echten Erfahrungen. Auf Projekten, die aus dem Ruder gelaufen sind, auf Budgets, die sich verdoppelt haben, auf Software, die am Bedarf vorbei gebaut wurde.
Die Angst ist berechtigt. Die Frage ist nur: Hilft sie uns – oder lähmt sie uns?
Was in der Blackbox passiert
Woher kommen diese Ängste? Sie kommen nicht aus dem Nichts – sie kommen aus dem, was in der Blackbox tatsächlich passiert. Da sitzen Spezialisten, und Spezialisten stellen Fragen. Ihr Job ist es, ihren Bereich abzusichern:
- „Wo wird das gehostet?“
- „Ist das skalierbar?“
- „Hast du an DevOps gedacht?“
- „Wie sieht die CI/CD-Pipeline aus?“
- „Was ist mit Security?“
Jede dieser Fragen ist berechtigt – irgendwo. Aber nicht jede ist relevant für dieses Projekt.
Der DevOps-Spezialist, der für ein Drei-Personen-Projekt erstmal einen Kubernetes-Cluster aufsetzt, Helm-Charts anlegt, eine Jenkins-Pipeline mit eigenem Build-Host konfiguriert, Infrastructure as Code implementiert – alles für eine Anwendung, die auf einem einzigen Server laufen könnte. Nicht weil es nötig ist, sondern weil er es so gelernt hat.
Für ihn ist das nicht Over-Engineering, das ist „richtig machen“. Er kann gar nicht anders denken. Der Spezialist sieht sein Spezialgebiet, er sieht nicht das Gesamtproblem. Er optimiert den Teil, den er kennt – und bläht ihn auf, weil er jeden Edge Case abdecken will, den er jemals gesehen hat, auch wenn dieser Edge Case hier nie eintreten wird.
Und während diese Fragen gestellt werden, läuft das eigentliche Problem weiter: Das gesamte Produktionswissen im Kopf eines 58-Jährigen, der nächstes Jahr in Rente geht. Die Zettelwirtschaft, die niemand anfasst. Die Excel-Tabelle, die weiter wächst.
Das ist, was in der Blackbox passiert. Fragen werden gestellt und beantwortet, die für dein Problem irrelevant sind. Jeder sichert seinen Bereich ab, die Zeit vergeht, die Kosten steigen – und du sitzt draußen und verstehst nicht, warum.
Was Pragmatismus bedeutet
Pragmatismus in der Softwareentwicklung heißt nicht, dass alles egal ist. Es heißt: Das Ziel ist nicht, den Prozess zu befolgen – das Ziel ist, das Problem zu lösen.
Es heißt, dass Ergebnis Eleganz schlägt, und dass eine funktionierende Lösung heute mehr wert ist als eine perfekte Lösung in sechs Monaten. Es heißt, dass nicht jede Frage beantwortet werden muss, bevor man anfängt – manche Fragen beantworten sich von selbst, wenn man erstmal etwas hat, das man anfassen kann.
Pragmatismus bedeutet auch, Entscheidungslast abzunehmen, ohne Verantwortung abzugeben. Die Verantwortung für die Daten, für den Prozess, für das Ergebnis – die bleibt beim Unternehmen. Aber die Frage, ob Railway oder AWS oder der Server im Keller, die muss nicht der Produktionsleiter beantworten. Dafür holt man sich jemanden, der das kann.
Ich nutze Services wie Railway, weil ich weiß, dass sie funktionieren. Ich verknüpfe ein GitHub-Repo, drücke auf Deploy, und habe alles was ich brauche – fertig. Der Spezialist würde fragen: „Aber was ist mit…?“ Und dann folgt eine Liste von Szenarien, die für dieses Projekt irrelevant sind.
Das Ziel ist Erleichterung. Die Erleichterung zu wissen, dass da jemand ist, der das für mich entscheidet, weil er die Konsequenzen einschätzen kann. Und der mir sagt, was ich wissen muss – nicht alles, was er weiß.
Aber: Pragmatismus ohne Erfahrung ist Pfusch
Hier ist die Kehrseite, und ich wäre nicht ehrlich, wenn ich sie verschweigen würde.
Pragmatismus bedeutet zu wissen, welche Abkürzungen man nehmen kann – und welche einem um die Ohren fliegen. Wer das nicht unterscheiden kann, baut keine schnelle Lösung, der baut technische Schulden, die jemand anders bezahlt.
Ich schreibe gerade einen Prototypen neu, den jemand mit KI „schnell mal gebaut“ hat. Das war auch pragmatisch gemeint – die Idee: Warum Wochen investieren, wenn ChatGPT das in Stunden ausspuckt?
Das Ergebnis: Sicherheitslücken, Daten frei zugänglich, keine Struktur, keine Erweiterbarkeit. Jede kleine Änderung bricht etwas anderes. Und das Ironische daran: Es war am Ende auch nicht schnell. Der vermeintlich schnelle Weg hat genauso lange gedauert – nur mit einem schlechten Ergebnis.
Pragmatismus heißt nicht „Hauptsache schnell“. Es heißt: Schnell dort, wo es geht, gründlich dort, wo es sein muss – und die Erfahrung zu haben, das eine vom anderen zu unterscheiden.
Die Balance
Zwei Extreme also: Zu viel Spezialisierung – die Blackbox – führt zu Lösungen, die überdimensioniert sind, ewig dauern und Probleme lösen, die keiner hat. Zu wenig Erfahrung führt zu Lösungen, die nicht funktionieren, unsicher sind und technische Schulden produzieren.
Pragmatismus liegt dazwischen. Es ist die Fähigkeit zu unterscheiden: Was muss solide sein, was muss nur funktionieren, wo lohnt sich Aufwand – und wo nicht?
Das erfordert Breite, genug Erfahrung in genug Bereichen, um zu wissen, wann „gut genug“ gut genug ist. Nicht weil man es nicht besser könnte – sondern weil besser hier keinen Unterschied macht.
Wie das konkret aussieht
Pragmatische Softwareentwicklung hat für mich drei Eigenschaften:
Schnell genug, um es zu sehen. Bevor die Angst sich aufbaut und bevor die Zweifel überhandnehmen, gibt es etwas Greifbares. Kein Pflichtenheft nach drei Monaten, sondern etwas, das läuft.
Einfach genug, um es zu verstehen. Nicht der Produktionsleiter muss Docker verstehen, aber er muss verstehen, was die Lösung tut und warum. Wenn ich das nicht erklären kann, ohne dass die Augen glasig werden, habe ich meinen Job nicht gemacht.
Ehrlich genug, um es zu glauben. Was geht, was nicht geht, was es kostet, was es bringt – kein Overselling, kein „das klären wir später“. Die unbequemen Wahrheiten am Anfang, nicht am Ende.
Der eigentliche Punkt
Software-Projekte sind komplex, und das wird sich nicht ändern. Du brauchst jemanden, der das für dich umsetzt – das ist klar.
Die Frage ist nur: Was passiert in der Zeit dazwischen? Zwischen „Ich habe ein Problem“ und „Hier ist die Lösung“?
Werden Prozesse gebaut, die sich selbst wachsen lassen? Werden Fragen beantwortet, die niemand gestellt hat? Wird optimiert, was nicht optimiert werden muss? Oder wird dein Problem gelöst – so direkt und so schlank wie möglich?
Pragmatismus ist das Versprechen, es auf die zweite Art zu machen: Die Komplexität minimal zu halten und nicht größer zu werden als nötig.
Das adressiert die Fragen, die du dir stellst:
„Habe ich den richtigen Dienstleister gewählt?“ – Ja, wenn er sich nicht wichtiger macht als dein Problem.
„Sind die Kosten das wert?“ – Ja, wenn du nicht für Dinge bezahlst, die du nicht brauchst.
Das ist keine Garantie, aber es ist eine Haltung. Und diese Haltung soll dir etwas geben: Erleichterung. Das Gefühl, dass da jemand ist, der versteht was du brauchst – der die Zettel sieht, nicht die Skalierungsfrage. Der fragt „Was nervt dich?“ statt „Wie hoch ist dein Budget?“ Und der dann einfach anfängt.