Ово није баг, ово је фича — суштина, порекло и разлике

Шта значи „Ово није баг, ово је фича”

„Ово није баг, ово је фича” — фраза којом програмер или менаџер означава да је неочекивано понашање програма намерно, а не погрешно. У класичном случају то је шала: сви разумеју да је понашање погрешно, али га називају „фичом” за смањење напетости. Међутим, у стварним пројектима фраза се користи и озбиљно — када понашање стварно одговара спецификацији, али не одговара очекивањима корисника.

Разлика између бага и фиче често је субјективна. Програмеру који је написао код, одређено понашање може изгледати логично. Кориснику — неочекивано и погрешно. Субјективност перцепције — главни разлог зашто је фраза тако жилава. Она омогућава пребацивање разговора из равни „ко је крив” у раван „тако је замишљено”. Према UX Collective, 40% багова пријављених од стране корисника су заправо UX проблеми, а не грешке у коду.

У agile тимовима, фраза се често користи као одбрамбени механизам на демо-у. Програмер показује неочекивано понашање, product owner се мршти и чује се сакраментално „ово није баг, ово је фича”. Поверење у тиму одређује да ли ће фраза бити прихваћена као шала или као покушај скривања проблема. У здравом тиму таква шала разбија напетост, у токсичном — изазива конфликт.

Историја настанка култне фразе

Прва позната употреба фразе забележена је 1976. године у једном од билтена DECUS (Digital Equipment Corporation User Society). Корисник се жалио да текст процесор RUNOFF неправилно обрађује празне редове. Одговор програмера: „Ово није баг, ово је фича — тако се обрађују параграфи”. Од тада, фраза је постала симбол одбране кода написаног „онако како јесте”, без обзира на његов стварни квалитет.

Популаризацији фразе допринео је Jargon File — речник хакерског сленга који је 1990-их година чинио основу књиге „The New Hacker's Dictionary”. У Jargon File-у чланак „feature” се директно односи на багове који су постали фиче због немогућности или невољности да се поправе. Пример: тастер Caps Lock у раним терминалима није имао индикацију — то је био баг који је постао фича „за слепо куцање”.

У 2000-им фраза је прешла у масовну културу путем интернет мемова. Слика мачке са натписом „It's not a bug, it's a feature” проширила се форумима и друштвеним мрежама. У индустрији игара фраза се користи посебно често: glitch-еви који не ометају гејмплеј проглашавају се „фичама” за атмосферу. Културни феномен је отишао далеко изван ИТ-а — фраза се може чути у било ком контексту где се оправдава грешка.

Психологија оправдања: зашто тако говоре

Психолошка основа фразе — когнитивни дисонанс. Програмер је провео сате пишући код, а признати да је резултат погрешан значи обезвредити свој рад. Фраза „ово није баг, ово је фича” смањује дисонанс: грешка се претвара у намерно решење, а програмер — из кривца у аутора замисли. Ово је одбрамбени механизам психе који чува самопоштовање.

Други разлог — страх од прераде. Ако се призна баг, мора се поново пролазити код-ревију, тестирање и деплој. „Фича” не захтева исправку — задатак се затвара, оптерећење се смањује. Према Microsoft Research-у, програмери свесно умањују озбиљност багова како би избегли прераде у 23% случајева. Фраза је благи облик таквог умањивања.

Трећи разлог — корпоративна култура. У неким компанијама, багови се урачунавају у KPI програмера, а откривање бага на код-ревију се сматра грешком аутора. У таквом окружењу фраза „ово није баг, ово је фича” је начин да се избегну негативне последице по каријеру. Здрава култура грешака (blameless culture) уклања овај разлог: ако се багови не кажњавају, лакше их је признати.

Где пролази граница између бага и фиче

Јасна граница постоји само уз Acceptance Criteria (критеријуме прихватања). Ако понашање не одговара ниједној тачки AC — то је баг. Ако понашање одговара AC, али се не свиђа кориснику — то је UX проблем, а не баг. Ако AC нема — било које понашање се може прогласити фичом, и то је главни разлог жилавости фразе.

Практично правило: баг — када програм ради оно што не би требало или не ради оно што би требало према спецификацији. Фича — када програм ради оно што је замишљено, чак и ако резултат изненађује корисника. Спорни случајеви: undefined behavior (језик не одређује резултат), race conditions (испољавају се нестабилно), екстремне вредности (ради за 99% података).

За разграничење користите матрицу одлука:

• Понашање описано у спецификацији и имплементирано коректно — фича, чак и ако вам се не свиђа
• Понашање описано, али имплементирано некоректно — баг, захтева исправку
• Понашање није описано, али логично произилази из захтева — недокументована фича, треба додати у спецификацију
• Понашање није описано и није логично — баг, захтева прецизирање захтева

Најопаснији случај — када спецификација не постоји, а програмер сам одлучује шта је фича. У таквим пројектима свака грешка може бити проглашена „фичом”, што чини код непредвидивим за цео тим. Јасни Acceptance Criteria за сваки задатак — једини начин да се граница повуче објективно.

Зашто је опасна замена појмова у тиму

Прва опасност — замагљивање квалитета. Ако се сваки баг може прогласити фичом, тим нема подстицај да пише квалитетан код. Грешке престају да се поправљају, технички дуг расте, а корисници се навикавају на „чудно понашање”. Пре или касније конкурент избацује производ који ради предвидиво и корисници одлазе.

Друга опасност — конфликти у тиму. QA инжењер проналази баг, програмер каже „ово је фича”. Ако нема објективних критеријума (Acceptance Criteria), спор прелази у личну раван: „ти лоше тестираш” vs „ти лоше програмираш”. Према PractiTest State of Testing 2023, спорови „баг vs фича” су један од три главна узрока трења између QA и програмера.

Трећа опасност — правни ризици. У регулисаним индустријама (медицина, финансије, ваздухопловство) појмови „баг” и „фича” имају правну тежину. Ако се у медицинском софтверу понашање прогласи фичом, а оно доводи до погрешног израчунавања дозе — то није шала, већ кршење регулаторних захтева. Safety-critical системи не праштају замену појмова, зато се у њима увек примењује formal verification.

Како спречити забуну између бага и фиче

Главни алат — јасни Acceptance Criteria (AC) у сваком задатку. AC се пишу пре почетка развоја: „При уносу X систем треба да изда Y”. Ако понашање није описано — то је подразумевани баг, чак и ако програмер мисли другачије. AC морају бити мерљиви и проверљиви: „дугме зелено” — лоше, „HEX #00FF00” — добро.

Други алат — Definition of Done у тиму. Јасан опис шта значи „задатак је завршен”: код написан, тестови написани, тестови пролазе, код-ревију завршен, деплој на стејџинг, тестиран од QA. Ако су све тачке DoD испуњене, а корисник се жали — то није баг, већ missed requirement који иде у беклог као нова фича.

Трећи алат — култура blameless post-mortem. Ако је баг проглашен фичом и отишао у продукцију — анализирамо узроке, а не тражимо кривца. Зашто је програмер одлучио да је ово фича? Зашто је QA пропустио? Зашто су AC били непотпуни? Одговори на ова питања побољшавају процес, а не кажњавају људе. Системска побољшања делују ефикасније од забране фразе „ово није баг, ово је фича”.