To nie bug, to feature — znaczenie, pochodzenie i różnice

Co oznacza „To nie bug, to feature”

„To nie bug, to feature” — powiedzenie, którym programista lub menedżer oznacza, że nieoczekiwane zachowanie programu jest zamierzone, a nie błędne. W klasycznym przypadku jest to żart: wszyscy rozumieją, że zachowanie jest błędne, ale nazywają je „feature'em” dla rozładowania napięcia. Jednak w rzeczywistych projektach fraza używana jest również na serio — gdy zachowanie rzeczywiście odpowiada specyfikacji, ale nie odpowiada oczekiwaniom użytkownika.

Różnica między bugiem a feature'em jest często subiektywna. Dla programisty, który napisał kod, pewne zachowanie może wydawać się logiczne. Dla użytkownika — nieoczekiwane i błędne. Subiektywność percepcji — główny powód, dla którego fraza jest tak żywotna. Pozwala przenieść rozmowę z płaszczyzny „kto jest winien” na płaszczyznę „tak zostało zaprojektowane”. Według UX Collective, 40% bugów zgłaszanych przez użytkowników to w rzeczywistości problemy UX, a nie błędy kodu.

W zespołach agile fraza często używana jest jako mechanizm obronny podczas demo. Programista pokazuje nieoczekiwane zachowanie, product owner marszczy brwi i pada sakramentalne „to nie bug, to feature”. Zaufanie w zespole decyduje, czy fraza zostanie odebrana jako żart, czy jako próba ukrycia problemu. W zdrowym zespole taki żart rozładowuje atmosferę, w toksycznym — wywołuje konflikt.

Historia powstania kultowego powiedzenia

Pierwsze znane użycie frazy odnotowano w 1976 roku w jednym z biuletynów DECUS (Digital Equipment Corporation User Society). Użytkownik skarżył się, że edytor tekstu RUNOFF nieprawidłowo przetwarza puste linie. Odpowiedź programisty: „To nie bug, to feature — w ten sposób przetwarzane są akapity”. Od tamtej pory fraza stała się symbolem obrony kodu napisanego „tak jak jest”, niezależnie od jego rzeczywistej jakości.

Do popularyzacji frazy przyczynił się Jargon File — słownik hakerskiego slangu, który w latach 90. stał się podstawą książki „The New Hacker's Dictionary”. W Jargon File hasło „feature” bezpośrednio odnosi się do bugów, które stały się feature'ami z powodu niemożności lub niechęci do ich naprawienia. Przykład: klawisz Caps Lock we wczesnych terminalach nie miał wskaźnika — był to bug, który stał się feature'em „do ślepego pisania”.

W latach 2000. fraza przeniknęła do kultury masowej za pośrednictwem memów internetowych. Obrazek z kotem podpisany „It's not a bug, it's a feature” rozszedł się po forach i mediach społecznościowych. W branży gier fraza używana jest szczególnie często: glitche, które nie przeszkadzają w rozgrywce, ogłaszane są „feature'ami” dla atmosfery. Fenomen kulturowy wyszedł daleko poza IT — frazę można usłyszeć w każdym kontekście, w którym usprawiedliwia się błąd.

Psychologia usprawiedliwiania: dlaczego tak się mówi

Psychologiczną podstawą frazy jest dysonans poznawczy. Programista spędził godziny na pisaniu kodu, a przyznanie, że wynik jest błędny, oznacza zdewaluowanie własnej pracy. Fraza „to nie bug, to feature” zmniejsza dysonans: błąd zamienia się w zamierzone rozwiązanie, a programista — z winowajcy w autora pomysłu. To mechanizm obronny psychiki, który chroni poczucie własnej wartości.

Drugi powód — strach przed przeróbkami. Jeśli przyznać się do buga, trzeba ponownie przejść code review, testowanie i wdrożenie. „Feature” nie wymaga poprawy — zadanie jest zamykane, obciążenie maleje. Według Microsoft Research, programiści świadomie zaniżają wagę bugów, aby uniknąć przeróbek, w 23% przypadków. Fraza jest łagodną formą takiego zaniżania.

Trzeci powód — kultura korporacyjna. W niektórych firmach bugi są uwzględniane w KPI programisty, a wykrycie buga podczas code review uznaje się za błąd autora. W takim środowisku fraza „to nie bug, to feature” to sposób na uniknięcie negatywnych konsekwencji dla kariery. Zdrowa kultura błędów (blameless culture) eliminuje ten powód: jeśli bugi nie są karane, łatwiej je przyznawać.

Gdzie przebiega granica między bugiem a feature'em

Wyraźna granica istnieje tylko przy Acceptance Criteria (kryteriach akceptacji). Jeśli zachowanie nie odpowiada żadnemu punktowi AC — to bug. Jeśli zachowanie odpowiada AC, ale nie podoba się użytkownikowi — to problem UX, a nie bug. Jeśli AC nie ma — każde zachowanie można ogłosić feature'em i to jest główna przyczyna żywotności frazy.

Praktyczna zasada: bug — to kiedy program robi to, czego nie powinien, lub nie robi tego, co powinien, zgodnie ze specyfikacją. Feature — to kiedy program robi to, co zostało zaprojektowane, nawet jeśli wynik zaskakuje użytkownika. Przypadki sporne: undefined behavior (język nie określa wyniku), race conditions (przejawiają się niestabilnie), wartości skrajne (działa dla 99% danych).

Do rozgraniczenia używaj macierzy decyzji:

• Zachowanie opisane w specyfikacji i zaimplementowane poprawnie — feature, nawet jeśli się nie podoba
• Zachowanie opisane, ale zaimplementowane niepoprawnie — bug, wymaga poprawy
• Zachowanie nieopisane, ale logicznie wynikające z wymagań — nieudokumentowany feature, należy dodać do specyfikacji
• Zachowanie nieopisane i nielogiczne — bug, wymaga doprecyzowania wymagań

Najbardziej niebezpieczny przypadek — gdy specyfikacja nie istnieje, a programista sam decyduje, co jest feature'em. W takich projektach każdy błąd może zostać ogłoszony „feature'em”, co czyni kod nieprzewidywalnym dla całego zespołu. Jasne Acceptance Criteria dla każdego zadania — jedyny sposób na obiektywne wyznaczenie granicy.

Dlaczego zamiana pojęć jest niebezpieczna w zespole

Pierwsze zagrożenie — rozmycie jakości. Jeśli każdy bug można ogłosić feature'em, zespół nie ma motywacji do pisania wysokiej jakości kodu. Błędy przestają być naprawiane, dług techniczny rośnie, a użytkownicy przyzwyczajają się do „dziwnego zachowania”. Prędzej czy później konkurent wypuszcza produkt działający przewidywalnie i użytkownicy odchodzą.

Drugie zagrożenie — konflikty w zespole. Inżynier QA znajduje buga, programista mówi „to feature”. Jeśli brak obiektywnych kryteriów (Acceptance Criteria), spór przechodzi w sferę osobistą: „źle testujesz” vs „źle programujesz”. Według PractiTest State of Testing 2023, spory „bug vs feature” to jedna z trzech głównych przyczyn tarcia między QA a programistami.

Trzecie zagrożenie — ryzyka prawne. W branżach regulowanych (medycyna, finanse, lotnictwo) pojęcia „bug” i „feature” mają wagę prawną. Jeśli w oprogramowaniu medycznym zachowanie zostanie ogłoszone feature'em, a prowadzi ono do nieprawidłowego obliczenia dawkowania — to nie żart, a naruszenie wymogów regulacyjnych. Systemy safety-critical nie wybaczają zamiany pojęć, dlatego zawsze stosuje się w nich formal verification.

Jak zapobiec pomyłkom między bugiem a feature'em

Głównym narzędziem są jasne Acceptance Criteria w każdym zadaniu. AC pisze się przed rozpoczęciem prac: „Po wprowadzeniu X system powinien zwrócić Y”. Jeśli zachowanie nie jest opisane — to domyślnie bug, nawet jeśli programista uważa inaczej. AC muszą być mierzalne i weryfikowalne: „przycisk zielony” — źle, „HEX #00FF00” — dobrze.

Drugim narzędziem jest Definition of Done w zespole. Jasny opis tego, co oznacza „zadanie wykonane”: kod napisany, testy napisane, testy przechodzą, code review zaliczone, wdrożone na staging, przetestowane przez QA. Jeśli wszystkie punkty DoD są spełnione, a użytkownik narzeka — to nie bug, a missed requirement, który trafia do backlogu jako nowy feature.

Trzecim narzędziem jest kultura blameless post-mortem. Jeśli bug został ogłoszony feature'em i trafił na produkcję — analizujemy przyczyny, a nie szukamy winnego. Dlaczego programista uznał, że to feature? Dlaczego QA przepuścił? Dlaczego AC były niekompletne? Odpowiedzi na te pytania usprawniają proces, a nie karzą ludzi. Usprawnienia systemowe działają skuteczniej niż zakaz frazy „to nie bug, to feature”.