Jedes Entwicklungsteam spricht einen Dialekt, in dem bestimmte Sätze etwas anderes bedeuten, als sie sagen. Nicht weil jemand lügt — meistens sind sie ernst gemeint —, sondern weil sie die höfliche Version von etwas Härterem sind.
Hier sind die, die ich am häufigsten höre, was sie eigentlich sagen, und die Frage, die dir eine echte Antwort statt einer Diskussion bringt.
"Das räumen wir später auf"
Heißt: Wir werden es nicht später aufräumen.
Später ist kein Zeitpunkt. Es gibt keinen Sprint namens Später und kein Ticket darin. Die Abkürzung, die du gleich nimmst, ist in zwei Jahren noch da — nur hängen dann drei Dinge davon ab.
Frag: "In welchem Sprint?" Wenn es eine Antwort und ein Ticket gibt, ist es ein echter Plan und die Abkürzung ist in Ordnung. Wenn die Antwort ein Gesichtsausdruck ist, habt ihr gerade beschlossen, das für immer zu behalten — was immer noch richtig sein kann, aber jetzt wissen alle, dass sie es beschließen.
"Bei mir läuft's"
Heißt: Unsere Umgebungen unterscheiden sich, und keiner von uns weiß wie.
Der Klassiker. Und es ist wirklich nützliche Information — es sagt dir, dass der Bug umgebungsbedingt ist und nicht logisch. Was es nicht ist: eine Verteidigung.
Frag: "Was ist an deiner Maschine anders?" In neun von zehn Fällen gibt es eine Antwort: eine PHP-Version, eine Extension, eine Umgebungsvariable, eine Datei, die nie committet wurde. Genau deshalb gehört die ganze Umgebung in einen Container im Repository — das Argument habe ich anderswo ausführlich gemacht.
"Das ist nur eine kleine Änderung"
Heißt: Ich habe über die Codeänderung nachgedacht und über nichts, was dahinter kommt.
Die Änderung ist wirklich klein. Die Migration, die Cache-Invalidierung, die zwei API-Konsumenten und die Testsuite, die die alte Form annimmt, sind es nicht.
Frag: "Klein in welchen Dateien?" Kleine Änderungen haben kleine Wirkradien. Wenn niemand den Wirkradius benennen kann, ist sie nicht klein — sie ist ungeprüft.
"Erst mal quick and dirty"
Heißt: Dirty auf jeden Fall. Quick ist die optimistische Hälfte.
Manchmal ist das genau richtig — eine Demo morgen, eine Deadline, die sich nicht verschiebt. Das Problem ist, dass das "erst mal" nirgendwo festgehalten wird, und ein halbes Jahr später liest eine neue Entwicklerin den Code als bewusste Designentscheidung und kopiert das Muster.
Frag: "Was genau ist dirty daran, und kann das in einen Kommentar?" Drei Zeilen, die sagen das ist eine Abkürzung, so sähe die echte Lösung aus, kosten nichts und ändern, wie die nächste Person damit umgeht.
"Das ist ein Legacy-Problem"
Heißt: Ich will das nicht verantworten.
Gelegentlich zutreffend. Meistens geht es darum, wer es geschrieben hat, und nicht darum, was es ist — und es hört auf, nützlich zu sein, sobald "Legacy" nur noch "vor meiner Zeit" bedeutet, denn alles, was du heute schreibst, ist in achtzehn Monaten jemandes Legacy.
Frag: "Funktioniert es?" Wenn ja, lass es in Ruhe und hör auf, es zu beschimpfen. Wenn nein, ist es ein Bug, und Bugs haben Verantwortliche, egal wer sie geschrieben hat.
"Das sollten wir mal refactoren"
Heißt: Ich mag diesen Code nicht.
Das ist nicht dasselbe, wie dass der Code ein Problem wäre. Code nicht zu mögen ist ein Gefühl; ein Refactoring ist eine Woche, in der nichts ausgeliefert wird, und das Risiko neuer Bugs ist real.
Frag: "Was kostet er uns so, wie er ist?" Wenn die Antwort "jede Änderung hier dauert drei Tage" ist — refactoren, es zahlt sich aus. Wenn die Antwort "er ist hässlich" ist, schreib auf, was du ändern würdest, warte, bis du das nächste Mal ohnehin dort arbeitest, und mach es dann.
"Das braucht der Kunde nicht"
Heißt: Ich will es nicht bauen, oder niemand hat den Kunden gefragt.
Manchmal stimmt es, und Scope zurückzuweisen gehört zum Job. Aber "das braucht der Kunde nicht", gesagt von jemandem, der nie mit dem Kunden gesprochen hat, ist eine Vermutung im Anzug.
Frag: "Wen haben wir gefragt?" Echte Antwort oder nicht — so oder so lernst du etwas.
"Das ist im Grunde fertig"
Heißt: Der Happy Path funktioniert.
Der ist wirklich der größte Teil und gleichzeitig der einfachste. Fehlerbehandlung, Validierung, Sonderfälle, Tests und das eigentliche Deployment sind das verbleibende "im Grunde", und sie brauchen routinemäßig noch mal genauso lange.
Frag: "Was fehlt noch?" Eine Liste heißt, es ist fast fertig. "Nur noch ein paar Kleinigkeiten" heißt, die Liste wurde noch nicht gemacht, und alles auf einer ungeschriebenen Liste ist größer, als du denkst.
"Wir sind agil"
Heißt, ungefähr in der Hälfte der Fälle: Wir schreiben nichts auf.
Agil ist ein Satz von Praktiken mit einer ordentlichen Portion Disziplin darin. Es ist kein Argument dafür, keine Spezifikation zu haben, zweimal pro Woche die Prioritäten zu wechseln oder Dokumentation wegzulassen. Wenn "wir sind agil" die Antwort auf "was bauen wir eigentlich?" ist, wird es als Schild benutzt.
Frag: "Was ist das Akzeptanzkriterium?" Du kannst so flexibel sein, wie du willst, was als Nächstes gebaut wird. Du kannst nicht flexibel sein bei der Frage, woran ihr merkt, dass es fertig ist.
"Kannst du da mal kurz draufschauen?"
Heißt: Ich hätte gern eine Stunde deiner Aufmerksamkeit, ohne sie zu buchen.
Nichts ist ein kurzer Blick. Das Problem von jemand anderem gut genug zu verstehen, um etwas Nützliches zu sagen, kostet echten Kontextwechsel, und die Kosten landen komplett bei dir.
Frag: "Was hast du schon versucht?" Das ist keine Abfuhr — es filtert die heraus, die sich beim Erzählen von selbst lösen, und die, die übrig bleiben, kommen mit gemachter Vorarbeit an.
"Diesen Teil des Systems versteht keiner"
Heißt: Eine Person hat es verstanden, und die ist weg.
Das ist der einzige Satz auf dieser Liste, den ich als Notfall behandeln würde. Jeder andere beschreibt Kosten, die ihr bewusst zahlt. Dieser beschreibt eine Komponente, die sich nicht sicher ändern lässt, und die richtige Reaktion darauf ist kein Schulterzucken.
Frag: "Was passiert, wenn es kaputtgeht?" Wenn die ehrliche Antwort "wissen wir nicht" ist, ist das eure nächste Priorität, egal was auf der Roadmap steht.
Warum überhaupt darüber reden
Keiner dieser Sätze wird böswillig gesagt. Es sind Abkürzungen, und Abkürzungen in der Sprache funktionieren wie Abkürzungen im Code: gelegentlich in Ordnung, als Gewohnheit teuer, und die Kosten zahlt, wer danach kommt.
Es geht nicht darum, jemanden zu ertappen. Es geht darum, dass eine einzige konkrete Frage aus einer vagen Übereinkunft eine echte Entscheidung macht — und eine echte Entscheidung kann man später nachlesen.
Sag "wir behalten diese Abkürzung, und zwar deshalb" statt "das räumen wir später auf", und am Code ändert sich nichts. Was sich ändert: In einem Jahr muss niemand raten, ob es Absicht war.