Ez nem bug, ez feature — lényeg, eredet és különbségek

Mit jelent „Ez nem bug, ez feature”

„Ez nem bug, ez feature” — egy mondás, amellyel a fejlesztő vagy menedzser jelzi, hogy a program váratlan viselkedése szándékos, nem hibás. Klasszikus esetben ez egy vicc: mindenki érti, hogy a viselkedés hibás, de „feature”-nek hívják a feszültség oldására. Valódi projektekben azonban a mondást komolyan is használják — amikor a viselkedés tényleg megfelel a specifikációnak, de nem felel meg a felhasználó elvárásainak.

A bug és feature közötti különbség gyakran szubjektív. Annak a fejlesztőnek, aki a kódot írta, egy bizonyos viselkedés logikusnak tűnhet. A felhasználónak — váratlannak és hibásnak. Az észlelés szubjektivitása — a fő ok, amiért a mondás ennyire életképes. Lehetővé teszi a beszélgetés áthelyezését a „ki a hibás” síkjából a „így lett tervezve” síkjába. Az UX Collective szerint a felhasználók által jelentett bugok 40%-a valójában UX probléma, nem kódhiba.

Az agile csapatokban a mondást gyakran használják védelmi mechanizmusként a demókon. A fejlesztő váratlan viselkedést mutat, a product owner összeráncolja a homlokát, és elhangzik a szentimentális „ez nem bug, ez feature”. A csapatba vetett bizalom határozza meg, hogy a mondást viccnek vagy probléma elrejtésére tett kísérletnek tekintik. Egy egészséges csapatban egy ilyen vicc oldja a feszültséget, egy toxikus csapatban konfliktust okoz.

A kultikus mondás keletkezésének története

A mondás első ismert használatát 1976-ban jegyezték fel a DECUS (Digital Equipment Corporation User Society) egyik közleményében. Egy felhasználó panaszolta, hogy a RUNOFF szövegszerkesztő helytelenül dolgozza fel az üres sorokat. A fejlesztő válasza: „Ez nem bug, ez feature — így dolgozzuk fel a bekezdéseket”. Azóta a mondás a „megírt kód” védelmének szimbólumává vált, függetlenül annak tényleges minőségétől.

A mondás népszerűsítéséhez hozzájárult a Jargon File — a hacker szleng szótára, amely az 1990-es években a „The New Hacker's Dictionary” című könyv alapját képezte. A Jargon File-ban a „feature” szócikk közvetlenül azokra a bugokra utal, amelyek a javítás lehetetlensége vagy vonakodás miatt váltak feature-vé. Példa: a Caps Lock billentyű a korai terminálokon nem rendelkezett jelzővel — ez egy bug volt, amely „vak gépelésre” szolgáló feature-vé vált.

A 2000-es években a mondás internetes mémeken keresztül került át a tömegkultúrába. Egy macskás kép az „It's not a bug, it's a feature” felirattal terjedt el a fórumokon és közösségi médiában. A játékiparban a mondást különösen gyakran használják: azokat a glitcheket, amelyek nem zavarják a játékmenetet, „feature”-nek nyilvánítják a hangulat kedvéért. A kulturális jelenség messze túllépett az IT-n — a mondás bármilyen kontextusban hallható, ahol egy hibát igazolnak.

A kifogás pszichológiája: miért mondják

A mondás pszichológiai alapja a kognitív disszonancia. A fejlesztő órákat töltött a kód írásával, és annak elismerése, hogy az eredmény hibás, a saját munka leértékelését jelentené. Az „ez nem bug, ez feature” mondás csökkenti a disszonanciát: a hiba szándékos döntéssé változik, a fejlesztő pedig a vétkesből az ötlet szerzőjévé válik. Ez a psziché védekező mechanizmusa, amely megőrzi az önbecsülést.

A második ok — félelem az átdolgozástól. Ha a bugot elismerik, újra kell menni a code review-n, tesztelésen és deploy-on. A „feature” nem igényel javítást — a feladat lezárul, a terhelés csökken. A Microsoft Research szerint a fejlesztők az esetek 23%-ában tudatosan csökkentik a bugok súlyosságát az átdolgozás elkerülése érdekében. A mondás egy ilyen csökkentés enyhe formája.

A harmadik ok — vállalati kultúra. Néhány vállalatnál a bugok beleszámítanak a fejlesztő KPI-jába, és a bug code review során történő felfedezését a szerző hibájának tekintik. Ilyen környezetben az „ez nem bug, ez feature” mondás egy módja a karrier negatív következményeinek elkerülésére. Az egészséges hibakultúra (blameless culture) kiküszöböli ezt az okot: ha a bugokat nem büntetik, könnyebb beismerni őket.

Hol húzódik a határ bug és feature között

Egyértelmű határ csak Acceptance Criteria (elfogadási kritériumok) megléte esetén létezik. Ha a viselkedés nem felel meg az AC egyetlen pontjának sem — az bug. Ha a viselkedés megfelel az AC-nek, de a felhasználónak nem tetszik — az UX probléma, nem bug. Ha nincs AC — bármilyen viselkedés feature-nek nyilvánítható, és ez a mondás életképességének fő oka.

Gyakorlati szabály: bug — amikor a program olyat tesz, amit nem kellene, vagy nem teszi meg, amit kellene a specifikáció szerint. Feature — amikor a program azt teszi, amit terveztek, még ha az eredmény meg is lepi a felhasználót. Vitatott esetek: undefined behavior (a nyelv nem határozza meg az eredményt), race conditions (instabilan jelentkeznek), szélső értékek (az adatok 99%-ára működik).

A megkülönböztetéshez használja a döntési mátrixot:

• A viselkedés le van írva a specifikációban és helyesen van implementálva — feature, még ha nem is tetszik
• A viselkedés le van írva, de helytelenül van implementálva — bug, javítást igényel
• A viselkedés nincs leírva, de logikusan következik a követelményekből — nem dokumentált feature, hozzá kell adni a specifikációhoz
• A viselkedés nincs leírva és nem logikus — bug, a követelmények pontosítását igényli

A legveszélyesebb eset — amikor nincs specifikáció, és a fejlesztő maga dönti el, mi a feature. Az ilyen projektekben bármilyen hiba „feature”-nek nyilvánítható, ami kiszámíthatatlanná teszi a kódot az egész csapat számára. Világos Acceptance Criteria minden feladathoz — az egyetlen mód a határ objektív meghúzására.

Miért veszélyes a fogalmak felcserélése a csapatban

Az első veszély — a minőség elmosódása. Ha minden bugot feature-nek lehet nyilvánítani, a csapatnak nincs ösztönzője minőségi kódot írni. A hibákat nem javítják, a technikai adósság nő, a felhasználók hozzászoknak a „furcsa viselkedéshez”. Előbb-utóbb a versenytárs kiszámítható terméket dob piacra, és a felhasználók elmennek.

A második veszély — konfliktusok a csapatban. A QA mérnök talál egy bugot, a fejlesztő azt mondja „ez feature”. Ha nincsenek objektív kritériumok (Acceptance Criteria), a vita személyes síkra terelődik: „te rosszul tesztelsz” vs „te rosszul programozol”. A PractiTest State of Testing 2023 szerint a „bug vs feature” viták a három fő súrlódási ok egyike a QA és a fejlesztők között.

A harmadik veszély — jogi kockázatok. A szabályozott iparágakban (orvostudomány, pénzügy, repülés) a „bug” és „feature” fogalmak jogi súllyal bírnak. Ha egy orvosi szoftverben egy viselkedést feature-nek nyilvánítanak, de az helytelen adagolási számításhoz vezet — az nem vicc, hanem szabályozási követelmények megsértése. A safety-critical rendszerek nem bocsátják meg a fogalmak felcserélését, ezért mindig formal verification-t alkalmaznak bennük.

Hogyan előzzük meg a bug és feature összetévesztését

A fő eszköz — világos Acceptance Criteria (AC) minden feladatban. Az AC-t a fejlesztés megkezdése előtt írják meg: „X bevitelénél a rendszernek Y-t kell adnia”. Ha a viselkedés nincs leírva — az alapértelmezés szerint bug, még ha a fejlesztő másképp is gondolja. Az AC-nek mérhetőnek és ellenőrizhetőnek kell lennie: „a gomb zöld” — rossz, „HEX #00FF00” — jó.

A második eszköz — Definition of Done a csapatban. Világos leírás arról, mit jelent „a feladat kész”: kód megírva, tesztek megírva, tesztek mennek, code review megtörtént, staging-re deployolva, QA által tesztelve. Ha a DoD összes pontja teljesül, de a felhasználó panaszkodik — az nem bug, hanem missed requirement, amely új feature-ként kerül a backlogba.

A harmadik eszköz — blameless post-mortem kultúra. Ha egy bugot feature-nek nyilvánítottak és élesbe került — elemezzük az okokat, nem keressük a bűnöst. Miért döntött a fejlesztő úgy, hogy ez feature? Miért hagyta ki a QA? Miért voltak hiányosak az AC-k? A válaszok ezekre a kérdésekre javítják a folyamatot, nem büntetik az embereket. A rendszerszintű fejlesztések hatékonyabbak, mint az „ez nem bug, ez feature” mondás betiltása.