Wir bauen zu wenig, weil wir zu viel planen.

Eine Anekdote

Vor zwei Jahren saß ich in einem Sprint-Refinement-Meeting, das den Großteil eines Donnerstagvormittags fraß. Zur Diskussion stand ein Feature, das vermutlich vier, vielleicht sechs Stunden Code brauchte — eine Filter-Komponente, nichts wildes. Wir diskutierten 90 Minuten. Der Diskurs entglitt mehrfach in die Frage, wie man die Komponente "zukunftssicher" bauen könnte. Was, wenn der Filter auch auf andere Listen angewendet wird? Was, wenn neue Kriterien dazukommen? Was, wenn die Backend-Schnittstelle sich ändert?

Ich erinnere mich an den Moment, in dem ich aus dem Fenster sah und dachte: wir haben die Zeit, dieses Feature zu bauen, schon mit Diskutieren verbraucht. Nicht ein bisschen. Komplett.

Wir haben das Meeting beendet, ohne Konsens zu erreichen. Es wurde auf nächsten Dienstag vertagt.

Die These

Engineering-Orgs, die einmal eine bestimmte Größe überschritten haben, kippen in einen Modus, in dem das Vermeiden-von-Fehlern zur einzigen Optimierungsachse wird. Ein nicht gebautes Feature kann nicht falsch sein. Eine nicht getroffene Entscheidung kann nicht kritisiert werden. Ein nicht-eingegangenes Risiko kann nicht in der Postmortem auftauchen.

Das Ergebnis ist nicht mehr Qualität. Es ist mehr Diskussion. Und Diskussion fühlt sich an wie Arbeit, ist aber meistens keine.

Eine Stunde Bauen schlägt zehn Stunden Diskutieren über das Bauen — fast immer, in fast jedem Kontext, in fast jeder Phase eines Produkts.

Plädoyer für die Schippe

Es gibt einen Moment in jedem Projekt, in dem man wissen sollte, ob die Idee überhaupt funktioniert. Und es gibt nur einen Weg, das herauszufinden: Du musst sie bauen. Nicht "spec'en". Nicht "evaluieren". Nicht "researchen". Bauen.

Was ich meine, ist nicht naive Code-Cowboy-Mentalität. Ich meine etwas spezifischeres: bei jeder Frage, bei der dir nicht klar ist, was die Antwort ist, ist die Antwort wahrscheinlich, einen Prototypen zu bauen, der die Frage beantwortet — und nicht, ein weiteres Meeting anzusetzen.

Hands-on

Ein paar konkrete Heuristiken, die mir in den letzten Jahren geholfen haben:

• 15-Minuten-Regel: Wenn ich eine Frage habe, deren Antwort durch einen 15-minütigen Spike beantwortbar ist, mache ich keinen Termin und schreibe keinen Slack-Thread. Ich mache den Spike.
• Wegwerf-Code-Permission: Code, der gebaut wird, um eine Frage zu beantworten, muss nicht produktionsreif sein. Es ist okay, nach dem Spike den ganzen Code zu löschen. Das ist sogar oft die richtige Lösung.
• Pre-Mortem-Allergie: Ich misstraue jeder Diskussion über "was, wenn das fehlschlägt", die mehr als 20 Minuten dauert, ohne dass jemand das eigentliche System angefasst hat.

Wie sieht das aus?

Hier ein typischer Spike. Frage: "Wie schnell ist die Such-API mit 100k Items?" — statt zwei Tage zu schätzen, fünf Minuten Code:

// spike.js — wegwerfen nach beantworteter frage
const items = Array.from({ length: 100_000 }, (_, i) => ({
  id: i,
  title: `item-${i}`,
  body: crypto.randomUUID().repeat(8),
}));

const term = 'abcde';
const t0 = performance.now();
const hits = items.filter(it => it.body.includes(term));
const t1 = performance.now();

console.log(`hits=${hits.length}  took=${(t1 - t0).toFixed(2)}ms`);
// → hits=312  took=18.40ms
// 100k linear scan ist also kein problem, fertig.

18 Millisekunden. Frage beantwortet. Wir bauen es. Wenn es in der Realität langsamer ist als hier, weil der echte Datensatz andere Eigenschaften hat — okay, dann optimieren wir. Aber wir haben jetzt einen Datenpunkt, statt einer Vermutung.

Eine Warnung an mich selbst

Ich kenne den Gegenargument-Reflex. Aber was, wenn man gar nicht weiß, was man bauen soll? Dann muss man doch erst diskutieren?

Stimmt — manchmal. Aber öfter, als wir denken, ist auch das eine Frage, die durch Bauen besser beantwortet wird. Nicht durch Bauen-was-fertig-werden-soll, sondern durch Bauen-um-zu-lernen. Ein Prototyp ist ein Argument in Code. Er ist fast immer überzeugender als ein gleich langer Doc.

Zum Schluss

Vor zwei Wochen habe ich eine Idee gehabt, die ich für komisch hielt. Sie hatte mich zwei Tage beschäftigt, und ich war mir sicher, dass sie nicht funktionieren würde. Ich habe sie an einem Samstagvormittag in vier Stunden gebaut. Sie hat funktioniert. Sie war nicht "komisch" — sie war einfach neu für mich.

Hätte ich gewartet, bis ich überzeugt gewesen wäre, hätte ich sie nie gebaut. Hätte ich ein Doc geschrieben und die Reaktion abgewartet, hätte ich sie auch nie gebaut. Aber weil ich sie gebaut habe, weiß ich jetzt, dass sie funktioniert.

Bau es. Heute. Vier Stunden. Wenn's funktioniert, weißt du was. Wenn nicht, weißt du auch was.

— dillenberg, mit Notizen-Gegenlesen von Claude. Köln, Mai 2026.