To není bug, to je feature — podstata, původ a rozdíly

Co znamená „To není bug, to je feature“

„To není bug, to je feature“ — fráze, kterou vývojář nebo manažer označuje, že neočekávané chování programu je záměrné, nikoli chybné. V klasickém případě jde o vtip: všichni chápou, že chování je chybné, ale nazývají ho „feature“ pro uvolnění napětí. V reálných projektech se však fráze používá i vážně — když chování skutečně odpovídá specifikaci, ale neodpovídá očekávání uživatele.

Rozdíl mezi bugem a feature je často subjektivní. Pro vývojáře, který napsal kód, může být určité chování logické. Pro uživatele — neočekávané a chybné. Subjektivita vnímání — hlavní důvod, proč je fráze tak houževnatá. Umožňuje přesunout rozhovor z roviny „kdo je vinen“ do roviny „tak je to navrženo“. Podle UX Collective je 40 % bugů nahlášených uživateli ve skutečnosti problémy UX, nikoli chyby kódu.

V agile týmech se fráze často používá jako obranný mechanismus při demo. Vývojář ukáže neočekávané chování, product owner se zamračí a ozve se svátostné „to není bug, to je feature“. Důvěra v týmu určuje, zda bude fráze vnímána jako vtip nebo jako pokus skrýt problém. Ve zdravém týmu takový vtip uvolní atmosféru, v toxickém vyvolá konflikt.

Historie vzniku kultovní fráze

První známé použití fráze bylo zaznamenáno v roce 1976 v jednom z bulletinů DECUS (Digital Equipment Corporation User Society). Uživatel si stěžoval, že textový procesor RUNOFF nesprávně zpracovává prázdné řádky. Odpověď vývojáře: „To není bug, to je feature — takto se zpracovávají odstavce“. Od té doby se fráze stala symbolem obrany kodu napsaného „jak je“, bez ohledu na jeho skutečnou kvalitu.

K popularizaci fráze přispěl Jargon File — slovník hackerského slangu, který v 90. letech tvořil základ knihy „The New Hacker's Dictionary“. V Jargon File se heslo „feature“ přímo odkazuje na bugy, které se staly feature kvůli nemožnosti nebo neochotě je opravit. Příklad: klávesa Caps Lock v raných terminálech neměla indikaci — byl to bug, který se stal feature „pro slepé psaní“.

Ve 2000. letech fráze přešla do masové kultury prostřednictvím internetových memů. Obrázek kočky s popiskem „It's not a bug, it's a feature“ se rozšířil po fórech a sociálních sítích. V herním průmyslu se fráze používá obzvláště často: glitche, které neovlivňují hratelnost, se prohlašují za „feature“ pro atmosféru. Kulturní fenomén dalece přesáhl IT — frázi lze slyšet v jakémkoli kontextu, kde se omlouvá chyba.

Psychologie omluvy: proč to říkají

Psychologickým základem fráze je kognitivní disonance. Vývojář strávil hodiny psaním kódu a přiznání, že výsledek je chybný, by znamenalo znehodnocení vlastní práce. Fráze „to není bug, to je feature“ snižuje disonanci: chyba se mění v záměrné rozhodnutí a vývojář — z viníka v autora nápadu. Toto je obranný mechanismus psychiky, který chová sebeúctu.

Druhý důvod — strach z přepracování. Pokud se bug přizná, je třeba znovu projít code review, testováním a deployem. „Feature“ nevyžaduje opravu — úkol se uzavře, zátěž klesá. Podle Microsoft Research vývojáři vědomě snižují závažnost bugů, aby se vyhnuli přepracování, ve 23 % případů. Fráze je mírnou formou takového snižování.

Třetí důvod — firemní kultura. V některých společnostech se bugy započítávají do KPI vývojáře a odhalení bugu při code review je považováno za chybu autora. V takovém prostředí je fráze „to není bug, to je feature“ způsobem, jak se vyhnout negativním důsledkům pro kariéru. Zdravá kultura chyb (blameless culture) tento důvod odstraňuje: pokud bugy nejsou trestány, je snazší je přiznat.

Kde leží hranice mezi bugem a feature

Jasná hranice existuje pouze s Acceptance Criteria (kritérii přijetí). Pokud chování neodpovídá žádnému bodu AC — je to bug. Pokud chování odpovídá AC, ale uživateli se nelíbí — je to problém UX, nikoli bug. Pokud AC neexistují — jakékoli chování lze prohlásit za feature, a to je hlavní důvod houževnatosti fráze.

Praktické pravidlo: bug — když program dělá to, co nemá, nebo nedělá to, co má podle specifikace. Feature — když program dělá to, co bylo zamýšleno, i když výsledek uživatele překvapí. Sporné případy: undefined behavior (jazyk neurčuje výsledek), race conditions (projevují se nestabilně), extrémní hodnoty (funguje pro 99 % dat).

Pro rozlišení použijte rozhodovací matici:

• Chování popsáno ve specifikaci a implementováno správně — feature, i když se vám nelíbí
• Chování popsáno, ale implementováno nesprávně — bug, vyžaduje opravu
• Chování nepopsáno, ale logicky vyplývá z požadavků — nedokumentovaná feature, je třeba přidat do specifikace
• Chování nepopsáno a nelogické — bug, vyžaduje upřesnění požadavků

Nejnebezpečnější případ — když specifikace neexistuje a vývojář sám rozhoduje, co je feature. V takových projektech lze jakoukoli chybu prohlásit za „feature“, což činí kód nepředvídatelným pro celý tým. Jasná Acceptance Criteria pro každý úkol — jediný způsob, jak hranici objektivně stanovit.

Proč je záměna pojmů v týmu nebezpečná

První nebezpečí — rozmazání kvality. Pokud lze každý bug prohlásit za feature, tým nemá motivaci psát kvalitní kód. Chyby přestávají být opravovány, technický dluh roste a uživatelé si zvykají na „podivné chování“. Dříve či později konkurent uvede předvídatelný produkt a uživatelé odejdou.

Druhé nebezpečí — konflikty v týmu. QA inženýr najde bug, vývojář řekne „to je feature“. Pokud neexistují objektivní kritéria (Acceptance Criteria), spor přechází do osobní roviny: „špatně testuješ“ vs „špatně programuješ“. Podle PractiTest State of Testing 2023 jsou spory „bug vs feature“ jedním ze tří hlavních důvodů tření mezi QA a vývojáři.

Třetí nebezpečí — právní rizika. V regulovaných odvětvích (medicína, finance, letectví) mají pojmy „bug“ a „feature“ právní váhu. Pokud je v medicínském softwaru chování prohlášeno za feature, ale vede k nesprávnému výpočtu dávkování — není to vtip, ale porušení regulatorních požadavků. Safety-critical systémy neodpouštějí záměnu pojmů, proto se v nich vždy používá formal verification.

Jak předejít záměně mezi bugem a feature

Hlavní nástroj — jasná Acceptance Criteria (AC) v každém úkolu. AC se píší před zahájením vývoje: „Při zadání X musí systém vydat Y“. Pokud chování není popsáno — je to standardně bug, i když si vývojář myslí opak. AC musí být měřitelná a ověřitelná: „tlačítko je zelené“ — špatně, „HEX #00FF00“ — dobře.

Druhý nástroj — Definition of Done v týmu. Jasný popis toho, co znamená „úkol je hotov“: kód napsán, testy napsány, testy procházejí, code review provedeno, deploynuto na staging, otestováno QA. Pokud jsou všechny body DoD splněny, ale uživatel si stěžuje — není to bug, ale missed requirement, který jde do backlogu jako nová feature.

Třetí nástroj — kultura blameless post-mortem. Pokud byl bug prohlášen za feature a dostal se do produkce — analyzujeme příčiny, nehledáme viníka. Proč se vývojář rozhodl, že je to feature? Proč to QA propustil? Proč byla AC neúplná? Odpovědi na tyto otázky zlepšují proces, netrestají lidi. Systémová zlepšení fungují efektivněji než zákaz fráze „to není bug, to je feature“.