Het is geen bug, het is een feature — essentie, oorsprong en verschillen

Wat betekent „Het is geen bug, het is een feature”

„Het is geen bug, het is een feature” — een uitspraak waarmee een ontwikkelaar of manager aangeeft dat onverwacht programmagedrag opzettelijk is, niet foutief. In het klassieke geval is het een grap: iedereen begrijpt dat het gedrag foutief is, maar noemt het een „feature” om de spanning te verlichten. In echte projecten wordt de uitspraak echter ook serieus gebruikt — wanneer het gedrag daadwerkelijk overeenkomt met de specificatie, maar niet voldoet aan de verwachtingen van de gebruiker.

Het verschil tussen een bug en een feature is vaak subjectief. Voor de ontwikkelaar die de code schreef, kan bepaald gedrag logisch lijken. Voor de gebruiker — onverwacht en foutief. De subjectiviteit van perceptie — de belangrijkste reden waarom de uitspraak zo hardnekkig is. Het verplaatst het gesprek van „wie is schuldig” naar „zo is het ontworpen”. Volgens UX Collective is 40% van de door gebruikers gemelde bugs eigenlijk UX-problemen, geen codefouten.

In agile teams wordt de uitspraak vaak gebruikt als verdedigingsmechanisme tijdens demo's. De ontwikkelaar toont onverwacht gedrag, de product owner fronst zijn wenkbrauwen en de gedenkwaardige „het is geen bug, het is een feature” klinkt. Vertrouwen in het team bepaalt of de uitspraak wordt gezien als een grap of een poging om een probleem te verbergen. In een gezond team ontspant zo'n grap de sfeer, in een giftig team veroorzaakt het conflict.

Geschiedenis van de iconische uitspraak

Het eerste bekende gebruik van de uitspraak werd in 1976 geregistreerd in een van de bulletins van DECUS (Digital Equipment Corporation User Society). Een gebruiker klaagde dat de tekstverwerker RUNOFF lege regels verkeerd verwerkte. Het antwoord van de ontwikkelaar: „Het is geen bug, het is een feature — zo worden paragrafen verwerkt”. Sindsdien is de uitspraak een symbool geworden van het verdedigen van code zoals die is, ongeacht de werkelijke kwaliteit.

De popularisering van de uitspraak werd gestimuleerd door het Jargon File — een woordenboek van hacker-jargon dat in de jaren 1990 de basis vormde voor het boek „The New Hacker's Dictionary”. In het Jargon File verwijst het artikel „feature” direct naar bugs die features werden vanwege de onmogelijkheid of onwil om ze te repareren. Voorbeeld: de Caps Lock-toets op vroege terminals had geen indicatie — het was een bug die een feature werd „voor blind typen”.

In de jaren 2000 migreerde de uitspraak via internetmemes naar de populaire cultuur. Een plaatje van een kat met het onderschrift „It's not a bug, it's a feature” verspreidde zich over forums en sociale media. In de game-industrie wordt de uitspraak bijzonder vaak gebruikt: glitches die de gameplay niet verstoren worden uitgeroepen tot „features” voor de sfeer. Het culturele fenomeen is ver buiten de IT gegaan — de uitspraak is te horen in elke context waar een fout wordt gerechtvaardigd.

Psychologie van het excuus: waarom zeggen ze het

De psychologische basis van de uitspraak is cognitieve dissonantie. De ontwikkelaar heeft uren besteed aan het schrijven van code en toegeven dat het resultaat foutief is, betekent zijn werk devalueren. De uitspraak „het is geen bug, het is een feature” vermindert de dissonantie: de fout verandert in een opzettelijke beslissing en de ontwikkelaar verandert van schuldige in bedenker van het idee. Dit is een verdedigingsmechanisme van de psyche dat het zelfrespect behoudt.

De tweede reden — angst voor herbewerking. Als de bug wordt toegegeven, moet het hele traject van code review, testen en deploy opnieuw worden doorlopen. Een „feature” vereist geen correctie — de taak wordt afgesloten, de werkdruk neemt af. Volgens Microsoft Research verlagen ontwikkelaars in 23% van de gevallen bewust de ernst van bugs om herbewerking te voorkomen. De uitspraak is een milde vorm van dergelijke bagatellisering.

De derde reden — bedrijfscultuur. In sommige bedrijven worden bugs meegenomen in de KPI van de ontwikkelaar en wordt het vinden van een bug tijdens code review beschouwd als een fout van de auteur. In zo'n omgeving is de uitspraak „het is geen bug, het is een feature” een manier om negatieve gevolgen voor de carrière te vermijden. Een gezonde foutencultuur (blameless culture) elimineert deze reden: als bugs niet worden bestraft, is het makkelijker ze toe te geven.

Waar ligt de grens tussen een bug en een feature

Een duidelijke grens bestaat alleen met Acceptance Criteria (acceptatiecriteria). Als het gedrag niet overeenkomt met enig punt van de AC — is het een bug. Als het gedrag voldoet aan de AC maar de gebruiker bevalt — is het een UX-probleem, geen bug. Als er geen AC zijn — kan elk gedrag worden uitgeroepen tot een feature, en dit is de belangrijkste reden voor de hardnekkigheid van de uitspraak.

Praktische regel: bug — wanneer het programma doet wat het niet zou moeten doen of niet doet wat het wel zou moeten doen volgens de specificatie. Feature — wanneer het programma doet wat bedoeld is, zelfs als het resultaat de gebruiker verrast. Betwiste gevallen: undefined behavior (de taal definieert het resultaat niet), race conditions (manifesteren zich instabiel), extreme waarden (werkt voor 99% van de gegevens).

Gebruik voor het onderscheid de beslissingsmatrix:

• Gedrag beschreven in de specificatie en correct geïmplementeerd — feature, zelfs als je het niet leuk vindt
• Gedrag beschreven maar incorrect geïmplementeerd — bug, vereist correctie
• Gedrag niet beschreven maar logisch voortvloeiend uit de vereisten — ongedocumenteerde feature, moet aan de specificatie worden toegevoegd
• Gedrag niet beschreven en onlogisch — bug, vereist verduidelijking van de vereisten

Het gevaarlijkste geval — wanneer er geen specificatie is en de ontwikkelaar zelf beslist wat een feature is. In zulke projecten kan elke fout worden uitgeroepen tot „feature”, wat de code onvoorspelbaar maakt voor het hele team. Duidelijke Acceptance Criteria voor elke taak — de enige manier om de grens objectief te trekken.

Waarom begripsverwarring gevaarlijk is in een team

Het eerste gevaar — kwaliteitsvervaging. Als elke bug kan worden uitgeroepen tot feature, heeft het team geen prikkel om kwalitatief goede code te schrijven. Fouten worden niet opgelost, technische schuld groeit en gebruikers wennen aan „vreemd gedrag”. Vroeg of laat brengt een concurrent een voorspelbaar product uit en vertrekken de gebruikers.

Het tweede gevaar — conflicten in het team. Een QA-ingenieur vindt een bug, de ontwikkelaar zegt „het is een feature”. Als er geen objectieve criteria (Acceptance Criteria) zijn, gaat het geschil naar een persoonlijk niveau: „jij test slecht” vs „jij programmeert slecht”. Volgens PractiTest State of Testing 2023 zijn geschillen „bug vs feature” een van de drie belangrijkste oorzaken van wrijving tussen QA en ontwikkelaars.

Het derde gevaar — juridische risico's. In gereguleerde industrieën (medisch, financieel, luchtvaart) hebben de begrippen „bug” en „feature” juridisch gewicht. Als in medische software een gedraging wordt uitgeroepen tot feature maar leidt tot een onjuiste doseringsberekening — is dat geen grap, maar een schending van wettelijke vereisten. Safety-critical systemen vergeven begripsverwarring niet, daarom wordt er altijd formal verification toegepast.

Hoe verwarring tussen bug en feature te voorkomen

Het belangrijkste instrument — duidelijke Acceptance Criteria (AC) in elke taak. AC worden geschreven vóór de start van de ontwikkeling: „Bij invoer van X moet het systeem Y opleveren”. Als het gedrag niet is beschreven — is het standaard een bug, zelfs als de ontwikkelaar er anders over denkt. AC moeten meetbaar en verifieerbaar zijn: „knop is groen” — slecht, „HEX #00FF00” — goed.

Het tweede instrument — Definition of Done in het team. Een duidelijke beschrijving van wat „taak voltooid” betekent: code geschreven, tests geschreven, tests geslaagd, code review gedaan, gedeployed naar staging, getest door QA. Als alle DoD-punten zijn vervuld maar de gebruiker klaagt — is het geen bug, maar een missed requirement die als nieuwe feature naar de backlog gaat.

Het derde instrument — blameless post-mortem cultuur. Als een bug is uitgeroepen tot feature en in productie is beland — analyseren we de oorzaken, niet wie de schuldige is. Waarom besloot de ontwikkelaar dat het een feature was? Waarom heeft QA het gemist? Waarom waren de AC onvolledig? Antwoorden op deze vragen verbeteren het proces, ze straffen geen mensen. Systeemverbeteringen werken effectiever dan een verbod op de uitspraak „het is geen bug, het is een feature”.