Det är inte en bugg, det är en funktion — innebörd, ursprung och skillnader

Vad betyder "Det är inte en bugg, det är en funktion"

"Det är inte en bugg, det är en funktion" — en fras som utvecklaren eller chefen använder för att indikera att programmets oväntade beteende är avsiktligt, inte felaktigt. I det klassiska fallet är det ett skämt: alla förstår att beteendet är felaktigt, men kallar det "funktion" för att lätta på spänningen. I verkliga projekt används frasen dock även på allvar — när beteendet faktiskt överensstämmer med specifikationen men inte motsvarar användarens förväntningar.

Skillnaden mellan en bugg och en funktion är ofta subjektiv. För utvecklaren som skrev koden kan ett visst beteende verka logiskt. För användaren — oväntat och felaktigt. Subjektiviteten i perception — den främsta anledningen till att frasen är så seglivad. Den gör det möjligt att flytta samtalet från planet "vem är skyldig" till planet "så här är det designat". Enligt UX Collective är 40% av buggarna som rapporteras av användare egentligen UX-problem, inte kodfel.

I agila team används frasen ofta som försvarsmekanism vid demo. Utvecklaren visar oväntat beteende, produktägaren rynkar pannan och det sakramentala "det är inte en bugg, det är en funktion" hörs. Förtroendet i teamet avgör om frasen uppfattas som ett skämt eller ett försök att dölja ett problem. I ett sunt team lägger ett sådant skämt atmosfären, i ett toxiskt team orsakar det konflikt.

Historien bakom den kultförklarade frasen

Den första kända användningen av frasen registrerades 1976 i en av DECUS (Digital Equipment Corporation User Society) bulletiner. En användare klagade på att textprocessorn RUNOFF behandlade tomma rader felaktigt. Utvecklarens svar: "Det är inte en bugg, det är en funktion — så här behandlas stycken". Sedan dess har frasen blivit en symbol för att försvara kod skriven "som den är", oavsett dess verkliga kvalitet.

Populariseringen av frasen hjälptes av Jargon File — en ordbok över hackerslang som på 1990-talet utgjorde grunden för boken "The New Hacker's Dictionary". I Jargon File hänvisar artikeln "feature" direkt till buggar som blev funktioner på grund av omöjligheten eller oviljan att fixa dem. Exempel: Caps Lock-tangenten på tidiga terminaler hade ingen indikering — det var en bugg som blev en funktion "för blindskrivning".

På 2000-talet övergick frasen till populärkulturen via internetmemes. En bild på en katt med texten "It's not a bug, it's a feature" spreds på forum och sociala medier. Inom spelindustrin används frasen särskilt ofta: glitchar som inte påverkar gameplay förklaras som "funktioner" för atmosfären. Det kulturella fenomenet har gått långt utanför IT — frasen kan höras i alla sammanhang där ett fel rättfärdigas.

Psykologin bakom ursäkten: varför säger de så

Den psykologiska grunden för frasen är kognitiv dissonans. Utvecklaren har lagt timmar på att skriva kod, och att erkänna att resultatet är felaktigt innebär att devalvera sitt eget arbete. Frasen "det är inte en bugg, det är en funktion" minskar dissonansen: felet förvandlas till ett avsiktligt beslut och utvecklaren — från skyldig till idéförfattare. Detta är en försvarsmekanism hos psyket som bevarar självkänslan.

Den andra anledningen — rädsla för omarbetning. Om buggen erkänns måste man gå igenom code review, testning och deploy igen. "Funktion" kräver ingen korrigering — uppgiften stängs, belastningen minskar. Enligt Microsoft Research sänker utvecklare medvetet allvarlighetsgraden på buggar för att undvika omarbetning i 23% av fallen. Frasen är en mild form av sådan nedgradering.

Den tredje anledningen — företagskultur. I vissa företag räknas buggar in i utvecklarens KPI och upptäckten av en bugg vid code review betraktas som författarens fel. I en sådan miljö är frasen "det är inte en bugg, det är en funktion" ett sätt att undvika negativa karriärkonsekvenser. En sund felkultur (blameless culture) eliminerar denna anledning: om buggar inte bestraffas är det lättare att erkänna dem.

Var går gränsen mellan bugg och funktion

En tydlig gräns finns endast med Acceptance Criteria (acceptanskriterier). Om beteendet inte överensstämmer med någon punkt i AC — är det en bugg. Om beteendet överensstämmer med AC men användaren inte gillar det — är det ett UX-problem, inte en bugg. Om AC saknas — kan vilket beteende som helst förklaras som en funktion, och detta är huvudorsaken till frasens seglivadhet.

Praktisk regel: bugg — när programmet gör vad det inte borde eller inte gör vad det borde enligt specifikationen. Funktion — när programmet gör vad som är avsett, även om resultatet överraskar användaren. Omtvistade fall: undefined behavior (språket definierar inte resultatet), race conditions (uppträder instabilt), extrema värden (fungerar för 99% av datan).

För att skilja, använd beslutsmatrisen:

• Beteende beskrivet i specifikationen och korrekt implementerat — funktion, även om du inte gillar det
• Beteende beskrivet men felaktigt implementerat — bugg, kräver korrigering
• Beteende inte beskrivet men logiskt härlett från kraven — odokumenterad funktion, måste läggas till i specifikationen
• Beteende inte beskrivet och ologiskt — bugg, kräver förtydligande av kraven

Det farligaste fallet — när specifikationen saknas och utvecklaren själv bestämmer vad som är en funktion. I sådana projekt kan vilket fel som helst förklaras som "funktion", vilket gör koden oförutsägbar för hela teamet. Tydliga Acceptance Criteria för varje uppgift — det enda sättet att dra gränsen objektivt.

Varför begreppsförväxling är farlig i ett team

Den första faran — kvalitetsförsämring. Om varje bugg kan förklaras som en funktion har teamet inget incitament att skriva kvalitetskod. Fel åtgärdas inte, teknisk skuld växer och användarna vänjer sig vid "konstigt beteende". Förr eller senare lanserar en konkurrent en förutsägbar produkt och användarna lämnar.

Den andra faran — konflikter i teamet. En QA-ingenjör hittar en bugg, utvecklaren säger "det är en funktion". Om det inte finns objektiva kriterier (Acceptance Criteria) övergår tvisten till en personlig nivå: "du testar dåligt" vs "du programmerar dåligt". Enligt PractiTest State of Testing 2023 är "bugg vs funktion"-tvister en av de tre främsta orsakerna till friktion mellan QA och utvecklare.

Den tredje faran — juridiska risker. I reglerade branscher (medicin, finans, flyg) har begreppen "bugg" och "funktion" juridisk tyngd. Om i medicinsk mjukvara ett beteende förklaras som en funktion men leder till felaktig dosberäkning — är det inte ett skämt, utan ett brott mot regulatoriska krav. Safety-critical system förlåter inte begreppsförväxling, därför tillämpas alltid formal verification i dem.

Hur man förebygger förväxling mellan bugg och funktion

Huvudverktyget — tydliga Acceptance Criteria (AC) i varje uppgift. AC skrivs innan utvecklingen påbörjas: "Vid inmatning av X ska systemet producera Y". Om beteendet inte är beskrivet — är det som standard en bugg, även om utvecklaren tycker annorlunda. AC måste vara mätbara och verifierbara: "knappen är grön" — dåligt, "HEX #00FF00" — bra.

Det andra verktyget — Definition of Done i teamet. En tydlig beskrivning av vad "uppgiften är klar" betyder: kod skriven, tester skrivna, tester godkända, code review genomförd, deployad till staging, testad av QA. Om alla DoD-punkter är uppfyllda men användaren klagar — är det inte en bugg, utan ett missed requirement som går till backloggen som en ny funktion.

Det tredje verktyget — blameless post-mortem-kultur. Om en bugg har förklarats som en funktion och hamnat i produktion — analyserar vi orsakerna, inte vem som är skyldig. Varför bestämde utvecklaren att det var en funktion? Varför missade QA det? Varför var AC ofullständiga? Svaren på dessa frågor förbättrar processen, de straffar inte människor. Systemförbättringar fungerar effektivare än ett förbud mot frasen "det är inte en bugg, det är en funktion".