Ito ay hindi bug, ito ay feature — diwa, pinagmulan at mga pagkakaiba

Ano ang ibig sabihin ng "Ito ay hindi bug, ito ay feature"

"Ito ay hindi bug, ito ay feature" — isang parirala kung saan ang developer o manager ay nagpapahiwatig na ang hindi inaasahang pag-uugali ng programa ay sinadya, hindi pagkakamali. Sa klasikong kaso ito ay isang biro: naiintindihan ng lahat na ang pag-uugali ay mali, ngunit tinatawag nila itong "feature" upang mapawi ang tensyon. Gayunpaman, sa mga totoong proyekto, ang parirala ay ginagamit din nang seryoso — kapag ang pag-uugali ay talagang tumutugma sa spec ngunit hindi tumutugma sa inaasahan ng user.

Ang pagkakaiba sa pagitan ng bug at feature ay madalas na subjective. Para sa developer na sumulat ng code, ang isang partikular na pag-uugali ay maaaring mukhang lohikal. Para sa user — hindi inaasahan at mali. Ang subjectividad ng persepsyon — ang pangunahing dahilan kung bakit napakatibay ng parirala. Pinapayagan nito na ilipat ang usapan mula sa antas ng "sino ang may kasalanan" patungo sa antas ng "ganito ang disenyo". Ayon sa UX Collective, 40% ng mga bug na naiulat ng mga user ay talagang mga problema sa UX, hindi mga error sa code.

Sa mga agile team, ang parirala ay madalas na ginagamit bilang mekanismo ng depensa sa demo. Ipinapakita ng developer ang hindi inaasahang pag-uugali, ang product owner ay kumukunot ang noo, at ang sakramental na "ito ay hindi bug, ito ay feature" ay naririnig. Ang tiwala sa koponan ay nagtatakda kung ang parirala ay makikita bilang biro o pagtatangka na itago ang problema. Sa isang malusog na koponan, ang gayong biro ay nagpapagaan ng kapaligiran; sa isang toxic na koponan, nagdudulot ito ng salungatan.

Kasaysayan ng paglitaw ng iconic na parirala

Ang unang kilalang paggamit ng parirala ay naitala noong 1976 sa isa sa mga bulletin ng DECUS (Digital Equipment Corporation User Society). Isang user ang nagreklamo na mali ang pagproseso ng text processor na RUNOFF sa mga walang laman na linya. Ang sagot ng developer: "Ito ay hindi bug, ito ay feature — ganito pinoproseso ang mga talata". Simula noon, ang parirala ay naging simbolo ng pagtatanggol ng code na isinulat "kung ano ito", anuman ang aktwal na kalidad nito.

Ang pagpapasikat ng parirala ay itinulong ng Jargon File — isang diksyunaryo ng hacker slang na noong 1990s ay naging batayan ng aklat na "The New Hacker's Dictionary". Sa Jargon File, ang artikulong "feature" ay direktang tumutukoy sa mga bug na naging feature dahil sa imposibilidad o pag-aatubili na ayusin ang mga ito. Halimbawa: ang Caps Lock key sa mga unang terminal ay walang indikasyon — ito ay isang bug na naging feature "para sa blind typing".

Noong 2000s, ang parirala ay lumipat sa popular na kultura sa pamamagitan ng internet memes. Isang larawan ng pusa na may caption na "It's not a bug, it's a feature" ay kumalat sa mga forum at social media. Sa industriya ng laro, ang parirala ay ginagamit lalo na madalas: ang mga glitch na hindi nakakaapekto sa gameplay ay idineklara na "feature" para sa atmospera. Ang kultural na penomenon ay lumampas nang husto sa IT — ang parirala ay maririnig sa anumang konteksto kung saan binibigyang-katwiran ang isang error.

Sikolohiya ng dahilan: bakit nila ito sinasabi

Ang sikolohikal na batayan ng parirala ay cognitive dissonance. Ang developer ay gumugol ng mga oras sa pagsulat ng code, at ang pag-amin na mali ang resulta ay nangangahulugang pagpapababa ng halaga ng sariling trabaho. Ang pariralang "ito ay hindi bug, ito ay feature" ay nagbabawas ng dissonance: ang error ay nagiging isang sinadyang desisyon, at ang developer — mula sa may sala ay nagiging may-akda ng ideya. Ito ay isang depensibong mekanismo ng pag-iisip na nagpapanatili ng pagpapahalaga sa sarili.

Ang pangalawang dahilan — takot sa muling paggawa. Kung aaminin ang bug, kailangang dumaan muli sa code review, testing at deploy. Ang "feature" ay hindi nangangailangan ng pag-aayos — ang gawain ay sarado, ang trabaho ay nababawasan. Ayon sa Microsoft Research, sinasadya ng mga developer na babaan ang severity ng mga bug upang maiwasan ang muling paggawa sa 23% ng mga kaso. Ang parirala ay isang banayad na anyo ng naturang pagbaba.

Ang pangatlong dahilan — kultura ng korporasyon. Sa ilang kumpanya, ang mga bug ay isinasaalang-alang sa KPI ng developer, at ang pagtuklas ng bug sa code review ay itinuturing na pagkakamali ng may-akda. Sa ganitong kapaligiran, ang pariralang "ito ay hindi bug, ito ay feature" ay isang paraan upang maiwasan ang mga negatibong kahihinatnan para sa karera. Ang malusog na kultura ng pagkakamali (blameless culture) ay nag-aalis ng dahilan na ito: kung ang mga bug ay hindi pinaparusahan, mas madaling aminin ang mga ito.

Nasaan ang hangganan sa pagitan ng bug at feature

Ang malinaw na hangganan ay umiiral lamang sa pagkakaroon ng Acceptance Criteria (mga pamantayan ng pagtanggap). Kung ang pag-uugali ay hindi tumutugma sa anumang punto ng AC — ito ay bug. Kung ang pag-uugali ay tumutugma sa AC ngunit hindi gusto ng user — ito ay problema sa UX, hindi bug. Kung walang AC — anumang pag-uugali ay maaaring ideklarang feature, at ito ang pangunahing dahilan ng pagiging matibay ng parirala.

Praktikal na patakaran: bug — kapag ang programa ay gumawa ng hindi dapat o hindi gumawa ng dapat ayon sa spec. Feature — kapag ang programa ay gumawa ng kung ano ang idinisenyo, kahit na ang resulta ay nagulat sa user. Mga kontrobersyal na kaso: undefined behavior (hindi tinutukoy ng wika ang resulta), race conditions (hindi matatag na lumilitaw), matinding halaga (gumagana para sa 99% ng data).

Para sa pagkakaiba, gamitin ang matrix ng desisyon:

• Ang pag-uugali ay inilarawan sa spec at naipatupad nang tama — feature, kahit hindi mo gusto
• Ang pag-uugali ay inilarawan ngunit naipatupad nang mali — bug, nangangailangan ng pag-aayos
• Ang pag-uugali ay hindi inilarawan ngunit lohikal na nagmumula sa mga kinakailangan — hindi dokumentadong feature, dapat idagdag sa spec
• Ang pag-uugali ay hindi inilarawan at hindi lohikal — bug, nangangailangan ng paglilinaw ng mga kinakailangan

Ang pinakamapanganib na kaso — kapag walang spec at ang developer mismo ang nagpasya kung ano ang feature. Sa ganitong mga proyekto, anumang error ay maaaring ideklarang "feature", na ginagawang unpredictable ang code para sa buong koponan. Ang malinaw na Acceptance Criteria para sa bawat gawain — ang tanging paraan upang iguhit ang hangganan nang obhetibo.

Bakit mapanganib ang pagpapalit ng konsepto sa koponan

Ang unang panganib — pagpalabo ng kalidad. Kung ang bawat bug ay maaaring ideklarang feature, ang koponan ay walang insentibo na sumulat ng de-kalidad na code. Ang mga error ay hindi naaayos, ang teknikal na utang ay lumalaki, at ang mga user ay nasasanay sa "kakaibang pag-uugali". Maya-maya, ang katunggali ay naglalabas ng produktong mahuhulaan at ang mga user ay umaalis.

Ang pangalawang panganib — mga salungatan sa koponan. Ang QA engineer ay nakakita ng bug, ang developer ay nagsasabing "ito ay feature". Kung walang obhetibong pamantayan (Acceptance Criteria), ang pagtatalo ay napupunta sa personal na antas: "mali ang pag-test mo" vs "mali ang pag-program mo". Ayon sa PractiTest State of Testing 2023, ang mga pagtatalo na "bug vs feature" ay isa sa tatlong pangunahing sanhi ng alitan sa pagitan ng QA at mga developer.

Ang pangatlong panganib — mga legal na panganib. Sa mga regulated na industriya (medikal, pananalapi, abyasyon), ang mga konsepto ng "bug" at "feature" ay may legal na timbang. Kung sa medikal na software ang isang pag-uugali ay idineklarang feature ngunit ito ay humahantong sa maling pagkalkula ng dosis — ito ay hindi biro, kundi paglabag sa mga kinakailangan ng regulasyon. Ang mga safety-critical system ay hindi nagpapatawad sa pagpapalit ng konsepto, kaya naman palaging ginagamit ang formal verification sa mga ito.

Paano maiwasan ang kalituhan sa pagitan ng bug at feature

Ang pangunahing kasangkapan — malinaw na Acceptance Criteria (AC) sa bawat gawain. Ang AC ay isinusulat bago magsimula ang pag-develop: "Kapag nag-input ng X, ang sistema ay dapat magbigay ng Y". Kung ang pag-uugali ay hindi inilarawan — ito ay bug bilang default, kahit na iba ang iniisip ng developer. Ang AC ay dapat masukat at mapatunayan: "berde ang button" — masama, "HEX #00FF00" — mabuti.

Ang pangalawang kasangkapan — Definition of Done sa koponan. Malinaw na paglalarawan kung ano ang ibig sabihin ng "tapos na ang gawain": nakasulat na code, nakasulat na mga test, pumasa ang mga test, tapos na ang code review, naka-deploy sa staging, nasubok ng QA. Kung ang lahat ng punto ng DoD ay natupad ngunit nagreklamo ang user — ito ay hindi bug, kundi missed requirement na napupunta sa backlog bilang bagong feature.

Ang pangatlong kasangkapan — kultura ng blameless post-mortem. Kung ang bug ay idineklarang feature at napunta sa produksyon — sinusuri natin ang mga dahilan, hindi hinahanap kung sino ang may kasalanan. Bakit nagpasya ang developer na ito ay feature? Bakit ito pinalampas ng QA? Bakit hindi kumpleto ang AC? Ang mga sagot sa mga tanong na ito ay nagpapabuti sa proseso, hindi nagpaparusa sa mga tao. Ang mga sistematikong pagpapabuti ay mas epektibo kaysa sa pagbabawal sa pariralang "ito ay hindi bug, ito ay feature".