Kein Bug, sondern ein Feature — Bedeutung, Herkunft und Unterschiede

Was bedeutet „Kein Bug, sondern ein Feature“

„Kein Bug, sondern ein Feature“ — ein Satz, mit dem ein Entwickler oder Manager anzeigt, dass ein unerwartetes Programmverhalten beabsichtigt und nicht fehlerhaft ist. Im klassischen Fall ist es ein Witz: jeder versteht, dass das Verhalten falsch ist, aber man nennt es „Feature“, um die Spannung zu lösen. In realen Projekten wird der Satz jedoch auch ernsthaft verwendet — wenn das Verhalten tatsächlich der Spezifikation entspricht, aber nicht den Erwartungen des Benutzers.

Der Unterschied zwischen einem Bug und einem Feature ist oft subjektiv. Für einen Entwickler, der den Code geschrieben hat, mag ein bestimmtes Verhalten logisch erscheinen. Für einen Benutzer mag es unerwartet und falsch erscheinen. Die Subjektivität der Wahrnehmung ist der Hauptgrund, warum der Satz so beständig ist. Er verlagert das Gespräch von „wer ist schuld“ zu „so war es entworfen“. Laut UX Collective sind 40% der von Benutzern gemeldeten Bugs tatsächlich UX-Probleme, keine Codefehler.

In agilen Teams wird der Satz während Demos oft als Abwehrmechanismus verwendet. Der Entwickler zeigt unerwartetes Verhalten, der Product Owner runzelt die Stirn, und der schicksalhafte Satz „Kein Bug, sondern ein Feature“ wird ausgesprochen. Das Vertrauen im Team bestimmt, ob der Satz als Witz oder als Versuch, ein Problem zu verbergen, aufgenommen wird. In einem gesunden Team entschärft ein solcher Witz die Situation, in einem toxischen verursacht er Konflikte.

Geschichte des ikonischen Satzes

Die erste bekannte Verwendung des Satzes wurde 1976 in einem Bulletin der DECUS (Digital Equipment Corporation User Society) aufgezeichnet. Ein Benutzer beschwerte sich, dass der Textprozessor RUNOFF leere Zeilen falsch behandelte. Die Antwort des Entwicklers: „Kein Bug, sondern ein Feature — so werden Absätze verarbeitet.“ Seitdem ist der Satz zu einem Symbol der Verteidigung von Code geworden, der „wie er ist“ geschrieben wurde, unabhängig von seiner tatsächlichen Qualität.

Zur Popularisierung des Satzes trug die Jargon File bei — ein Wörterbuch der Hacker-Sprache, das in den 1990er Jahren die Grundlage für das Buch „The New Hacker’s Dictionary“ bildete. In der Jargon File verweist der Eintrag „feature“ direkt auf Bugs, die zu Features wurden, weil sie nicht behoben werden konnten oder sollten. Beispiel: Die Feststelltaste auf frühen Terminals hatte keine Anzeigeleuchte — das war ein Bug, der zu einem Feature „für Blindenschreiben“ wurde.

In den 2000er Jahren wanderte der Satz durch Internet-Memes in die Populärkultur. Ein Bild einer Katze mit der Bildunterschrift „It’s not a bug, it’s a feature“ verbreitete sich in Foren und sozialen Medien. In der Spieleindustrie wird der Satz besonders häufig verwendet: Glitches, die das Gameplay nicht beeinträchtigen, werden für die Atmosphäre zu „Features“ erklärt. Das kulturelle Phänomen hat sich weit über die IT hinaus verbreitet — der Satz ist in jedem Kontext zu hören, in dem ein Fehler gerechtfertigt wird.

Psychologie der Ausrede: warum man das sagt

Die psychologische Grundlage des Satzes ist die kognitive Dissonanz. Ein Entwickler hat Stunden damit verbracht, Code zu schreiben, und zuzugeben, dass das Ergebnis falsch ist, bedeutet, seine Arbeit zu entwerten. Der Satz „Kein Bug, sondern ein Feature“ reduziert die Dissonanz: der Fehler wird zu einer bewussten Entscheidung, und der Entwickler wird vom Schuldigen zum Urheber der Idee. Es ist ein psychologischer Abwehrmechanismus, der das Selbstwertgefühl bewahrt.

Der zweite Grund ist die Angst vor Nacharbeit. Einen Bug zuzugeben bedeutet, Code-Review, Tests und Deployment erneut durchlaufen zu müssen. Ein „Feature“ erfordert keine Korrektur — die Aufgabe wird geschlossen, die Arbeitslast sinkt. Laut Microsoft Research unterschätzen Entwickler in 23% der Fälle bewusst die Schwere von Bugs, um Nacharbeit zu vermeiden. Der Satz ist eine milde Form dieser Unterschätzung.

Der dritte Grund ist die Unternehmenskultur. In manchen Unternehmen beeinflussen Bugs die KPIs des Entwicklers, und das Finden eines Bugs im Code-Review gilt als Fehler des Autors. In einem solchen Umfeld ist der Satz „Kein Bug, sondern ein Feature“ ein Weg, negative Karrierefolgen zu vermeiden. Eine gesunde Fehlerkultur (beschuldigungsfreie Kultur) beseitigt diesen Grund: wenn Bugs nicht bestraft werden, sind sie leichter einzugestehen.

Wo die Grenze zwischen Bug und Feature verläuft

Eine klare Grenze existiert nur, wenn es Abnahmekriterien gibt. Wenn das Verhalten mit keinem Punkt der Abnahmekriterien übereinstimmt — ist es ein Bug. Wenn das Verhalten den Abnahmekriterien entspricht, der Benutzer es aber nicht mag — ist es ein UX-Problem, kein Bug. Wenn es keine Abnahmekriterien gibt — kann jedes Verhalten als Feature deklariert werden, und das ist der Hauptgrund für die Beständigkeit des Satzes.

Eine praktische Regel: Ein Bug liegt vor, wenn ein Programm etwas tut, was es nicht tun sollte, oder etwas nicht tut, was es tun sollte, gemäß der Spezifikation. Ein Feature liegt vor, wenn ein Programm das tut, was beabsichtigt war, auch wenn das Ergebnis den Benutzer überrascht. Grenzfälle: undefiniertes Verhalten (die Sprache definiert das Ergebnis nicht), Race Conditions (treten unregelmäßig auf), Extremwerte (funktioniert für 99% der Daten).

Zur Verdeutlichung verwenden Sie eine Entscheidungsmatrix:

• Verhalten ist in der Spezifikation beschrieben und korrekt implementiert — Feature, auch wenn es Ihnen nicht gefällt
• Verhalten ist beschrieben, aber falsch implementiert — Bug, Korrektur erforderlich
• Verhalten ist nicht beschrieben, ergibt sich aber logisch aus den Anforderungen — undokumentiertes Feature, muss zur Spezifikation hinzugefügt werden
• Verhalten ist nicht beschrieben und unlogisch — Bug, Anforderungen müssen geklärt werden

Der gefährlichste Fall ist, wenn es keine Spezifikation gibt und der Entwickler selbst entscheidet, was ein Feature ist. In solchen Projekten kann jeder Fehler als „Feature“ deklariert werden, was den Code für das gesamte Team unberechenbar macht. Klare Abnahmekriterien für jede Aufgabe — der einzige Weg, die Grenze objektiv zu ziehen.

Warum die Begriffssubstitution im Team gefährlich ist

Die erste Gefahr ist die Qualitätserosion. Wenn jeder Bug als Feature deklariert werden kann, hat das Team keinen Anreiz, qualitativ hochwertigen Code zu schreiben. Fehler werden nicht mehr behoben, die technische Schuld wächst, und die Benutzer gewöhnen sich an „merges Verhalten“. Früher oder später bringt ein Konkurrent ein Produkt heraus, das vorhersehbar funktioniert, und die Benutzer gehen.

Die zweite Gefahr sind Teamkonflikte. Ein QA-Ingenieur findet einen Bug, ein Entwickler sagt „Das ist ein Feature“. Ohne objektive Kriterien (Abnahmekriterien) wird die Diskussion persönlich: „Du testest schlecht“ vs „Du programmierst schlecht“. Laut PractiTest State of Testing 2023 sind „Bug vs Feature“-Streitigkeiten eine der drei Hauptursachen für Reibungen zwischen QA und Entwicklern.

Die dritte Gefahr sind rechtliche Risiken. In regulierten Branchen (Medizin, Finanzen, Luftfahrt) haben die Begriffe „Bug“ und „Feature“ rechtliches Gewicht. Wenn in einer medizinischen Software ein Verhalten als Feature deklariert wird, aber zu einer falschen Dosierungsberechnung führt — das ist kein Witz, sondern ein Verstoß gegen regulatorische Anforderungen. Sicherheitskritische Systeme tolerieren keine Begriffssubstitution, weshalb sie immer formale Verifikation verwenden.

Wie man Verwechslungen zwischen Bug und Feature verhindert

Das wichtigste Werkzeug sind klare Abnahmekriterien in jeder Aufgabe. Abnahmekriterien werden vor Entwicklungsbeginn geschrieben: „Bei Eingabe von X muss das System Y ausgeben.“ Wenn das Verhalten nicht beschrieben ist — ist es standardmäßig ein Bug, selbst wenn der Entwickler anderer Meinung ist. Abnahmekriterien sollten messbar und überprüfbar sein: „Der Button ist grün“ ist schlecht, „HEX #00FF00“ ist gut.

Das zweite Werkzeug ist eine Definition of Done im Team. Eine klare Beschreibung, was „Aufgabe erledigt“ bedeutet: Code geschrieben, Tests geschrieben, Tests bestanden, Code-Review abgeschlossen, auf Staging deployed, von QA getestet. Wenn alle Punkte der Definition of Done erfüllt sind und der Benutzer sich immer noch beschwert — ist es kein Bug, sondern eine übersehene Anforderung, die als neues Feature ins Backlog geht.

Das dritte Werkzeug ist eine beschuldigungsfreie Post-Mortem-Kultur. Wenn ein Bug als Feature deklariert wurde und in die Produktion gelangt ist — analysieren wir die Ursachen, suchen keinen Schuldigen. Warum dachte der Entwickler, es sei ein Feature? Warum hat QA es übersehen? Warum waren die Abnahmekriterien unvollständig? Antworten auf diese Fragen verbessern den Prozess, bestrafen keine Menschen. Systemische Verbesserungen wirken effektiver als ein Verbot des Satzes „Kein Bug, sondern ein Feature“.