Hauptgedanke

Ein Teil der Defekte kommt nicht aus dem Code, sondern aus dem, was ihm vorausging: eine unvollständige Spezifikation, eine mehrdeutige Produktentscheidung, ein nie bedachter Grenzfall, ein schlecht verstandener Ablauf. Diese Feststellung dient gewöhnlich der Entlastung — „das ist kein Bug, die Spec war unklar“. In Wirklichkeit führt sie woandershin.

Wenn der Rahmen nicht klar genug ist, um korrekt zu liefern, kann der, der liefern soll, das sagen und innehalten. Ablehnen heißt nicht blockieren: Es heißt, die Anfrage zur Klärung zurückzugeben — das erwartete Verhalten, die Grenzfälle, die Abnahmekriterien, die Daten, die Abhängigkeiten, die Risiken. Vor dem Programmieren nachzufragen kostet eine Diskussion; im Unklaren zu programmieren kostet eine wackelige Funktionalität, danach Defekte, Support, Rework und Abwägungen, die man neu treffen muss.

Die Grundlage ist einfach: Man kann die Qualität dessen nicht gewährleisten, was man nicht versteht. Ein Entwickler, der eine mehrdeutige Anfrage ausführt, entscheidet die Mehrdeutigkeiten allein, ohne es zu sagen und oft ohne es zu wissen.

Warum das wichtig ist

Das verwandelt eine wiederkehrende Klage in ein Recht, das mit einer Pflicht einhergeht. Solange die unklare Spezifikation nur ein Vorwurf ist, erzeugt sie Defekte, die man danach dem anlastet, der die Frage nicht gestellt hat.

Es präzisiert auch, wo sich Produktverantwortung und technische Verantwortung treffen: Das Produkt muss seine Entscheidung klären, die Technik darf eine starke Mehrdeutigkeit nicht in fragilen Code verwandeln.

Nuancen und Grenzen

Das Recht abzulehnen verkommt schnell. Wird es genutzt, um vor jeder Zeile Code eine erschöpfende Spezifikation zu verlangen, baut es ein V-Modell wieder auf und leugnet den Anteil an Unsicherheit, den das Team auffangen soll.

Die Linie lautet nicht „alles ist aufgeschrieben“, sondern „ich weiß, welches Verhalten ich wahr machen muss“ — eine Grenze, die vom gemeinsamen Kontext des Teams abhängt und die keine Vorlage an seiner Stelle festlegt.

Offene Fragen

• Wer entscheidet, wenn das Produkt die Anfrage für klar genug hält und das Entwicklungsteam das Gegenteil?