Non è un bug, è una feature — significato, origine e differenze

Cosa significa “Non è un bug, è una feature”

“Non è un bug, è una feature” — una frase usata da uno sviluppatore o manager per indicare che un comportamento inaspettato del programma è intenzionale, non erroneo. Nel caso classico, è uno scherzo: tutti capiscono che il comportamento è sbagliato, ma lo chiamano “feature” per alleviare la tensione. Tuttavia, nei progetti reali, la frase viene usata anche seriamente — quando il comportamento corrisponde effettivamente alla specifica ma non soddisfa le aspettative dell’utente.

La differenza tra un bug e una feature è spesso soggettiva. Per uno sviluppatore che ha scritto il codice, un certo comportamento può sembrare logico. Per un utente, può sembrare inaspettato ed erroneo. La soggettività della percezione è la ragione principale per cui la frase è così persistente. Sposta la conversazione da “chi è il colpevole” a “è stato progettato così”. Secondo UX Collective, il 40% dei bug segnalati dagli utenti sono in realtà problemi di UX, non errori di codice.

Nei team agili, la frase viene spesso usata come meccanismo di difesa durante le demo. Lo sviluppatore mostra un comportamento inaspettato, il product owner aggrotta le sopracciglia, e viene pronunciata la fatidica frase “non è un bug, è una feature”. La fiducia nel team determina se la frase verrà presa come uno scherzo o come un tentativo di nascondere un problema. In un team sano, uno scherzo del genere allenta la tensione; in uno tossico, provoca conflitto.

Storia della frase iconica

Il primo uso conosciuto della frase fu registrato nel 1976 in un bollettino della DECUS (Digital Equipment Corporation User Society). Un utente si lamentava che il processore di testo RUNOFF gestiva erroneamente le righe vuote. La risposta dello sviluppatore: “Non è un bug, è una feature — è così che vengono elaborati i paragrafi.” Da allora, la frase è diventata un simbolo di difesa del codice scritto “così com’è”, indipendentemente dalla sua qualità effettiva.

Alla divulgazione della frase ha contribuito il Jargon File — un dizionario del gergo hacker che negli anni ’90 è diventato la base del libro “The New Hacker’s Dictionary”. Nel Jargon File, la voce “feature” si riferisce direttamente ai bug che sono diventati feature perché era impossibile o indesiderabile correggerli. Esempio: il tasto Bloc Maiusc sui primi terminali non aveva un indicatore luminoso — questo era un bug che è diventato una feature “per la digitazione cieca”.

Negli anni 2000, la frase è passata alla cultura popolare attraverso i meme di Internet. Un’immagine di un gatto con la didascalia “It’s not a bug, it’s a feature” si è diffusa su forum e social media. Nell’industria dei videogiochi, la frase è usata particolarmente spesso: i glitch che non influenzano il gameplay vengono dichiarati “feature” per l’atmosfera. Il fenomeno culturale si è esteso ben oltre l’IT — la frase si può sentire in qualsiasi contesto in cui si giustifica un errore.

Psicologia della scusa: perché si dice

Il fondamento psicologico della frase è la dissonanza cognitiva. Uno sviluppatore ha passato ore a scrivere codice, e ammettere che il risultato è sbagliato significa svalutare il proprio lavoro. La frase “non è un bug, è una feature” riduce la dissonanza: l’errore si trasforma in una decisione deliberata, e lo sviluppatore passa da colpevole ad autore dell’idea. È un meccanismo di difesa psicologica che preserva l’autostima.

La seconda ragione è la paura del rifacimento. Ammettere un bug significa dover ripassare dalla revisione del codice, dai test e dal deployment. Una “feature” non richiede correzione — il compito viene chiuso, il carico di lavoro diminuisce. Secondo Microsoft Research, gli sviluppatori sottovalutano deliberatamente la gravità dei bug per evitare rifacimenti nel 23% dei casi. La frase è una forma lieve di questa sottovalutazione.

La terza ragione è la cultura aziendale. In alcune aziende, i bug influenzano i KPI dello sviluppatore, e trovare un bug durante la revisione del codice è considerato un errore dell’autore. In un tale ambiente, la frase “non è un bug, è una feature” è un modo per evitare conseguenze negative per la carriera. Una cultura dell’errore sana (cultura senza colpa) elimina questa ragione: se i bug non vengono puniti, è più facile ammetterli.

Dove passa il confine tra bug e feature

Un confine chiaro esiste solo quando ci sono Criteri di Accettazione. Se il comportamento non corrisponde a nessun punto dei CA — è un bug. Se il comportamento corrisponde ai CA ma all’utente non piace — è un problema di UX, non un bug. Se non ci sono CA — qualsiasi comportamento può essere dichiarato feature, e questa è la ragione principale della persistenza della frase.

Una regola pratica: un bug è quando un programma fa qualcosa che non dovrebbe, o non fa qualcosa che dovrebbe, secondo la specifica. Una feature è quando un programma fa ciò che era previsto, anche se il risultato sorprende l’utente. Casi limite: comportamento indefinito (il linguaggio non definisce il risultato), condizioni di gara (si manifestano in modo intermittente), casi estremi (funziona per il 99% dei dati).

Per chiarezza, utilizzare una matrice decisionale:

• Il comportamento è descritto nella specifica e implementato correttamente — feature, anche se non piace
• Il comportamento è descritto ma implementato in modo errato — bug, necessita di correzione
• Il comportamento non è descritto ma deriva logicamente dai requisiti — feature non documentata, va aggiunta alla specifica
• Il comportamento non è descritto ed è illogico — bug, i requisiti vanno chiariti

Il caso più pericoloso è quando non c’è specifica e lo sviluppatore decide da solo cosa sia una feature. In tali progetti, qualsiasi errore può essere dichiarato “feature”, rendendo il codice imprevedibile per l’intero team. Criteri di Accettazione chiari per ogni compito — l’unico modo per tracciare il confine oggettivamente.

Perché la sostituzione di concetti è pericolosa nel team

Il primo pericolo è l’erosione della qualità. Se ogni bug può essere dichiarato feature, il team non ha incentivi a scrivere codice di qualità. Gli errori smettono di essere corretti, il debito tecnico cresce e gli utenti si abituano a “comportamenti strani”. Prima o poi, un concorrente lancia un prodotto che funziona in modo prevedibile e gli utenti se ne vanno.

Il secondo pericolo è il conflitto nel team. Un ingegnere QA trova un bug, uno sviluppatore dice “è una feature”. Senza criteri oggettivi (Criteri di Accettazione), la discussione diventa personale: “testi male” vs “programmi male”. Secondo PractiTest State of Testing 2023, le dispute “bug vs feature” sono una delle tre principali cause di attrito tra QA e sviluppatori.

Il terzo pericolo sono i rischi legali. Nei settori regolamentati (medicina, finanza, aviazione), i concetti di “bug” e “feature” hanno peso legale. Se in un software medico un comportamento viene dichiarato feature ma porta a un calcolo errato del dosaggio — non è uno scherzo, ma una violazione dei requisiti normativi. I sistemi critici per la sicurezza non tollerano la sostituzione di concetti, quindi utilizzano sempre la verifica formale.

Come prevenire la confusione tra bug e feature

Lo strumento principale — Criteri di Accettazione chiari in ogni compito. I CA vengono scritti prima dell’inizio dello sviluppo: “Inserendo X, il sistema deve produrre Y”. Se il comportamento non è descritto — è un bug per impostazione predefinita, anche se lo sviluppatore la pensa diversamente. I CA devono essere misurabili e verificabili: “il pulsante è verde” è male, “HEX #00FF00” è bene.

Il secondo strumento — una Definizione di Fatto nel team. Una descrizione chiara di cosa significa “compito completato”: codice scritto, test scritti, test superati, revisione del codice completata, distribuito in staging, testato dal QA. Se tutti i punti della Definizione di Fatto sono soddisfatti e l’utente si lamenta ancora — non è un bug, ma un requisito mancante che va nel backlog come nuova feature.

Il terzo strumento — una cultura di post-mortem senza colpa. Se un bug è stato dichiarato feature ed è finito in produzione — analizziamo le cause, non cerchiamo un colpevole. Perché lo sviluppatore pensava fosse una feature? Perché il QA non l’ha visto? Perché i CA erano incompleti? Le risposte a queste domande migliorano il processo, non puniscono le persone. I miglioramenti sistemici funzionano in modo più efficace del vietare la frase “non è un bug, è una feature”.