Bug cosa significa

Etimologia del termine bug

Oggi quando diciamo “bug” pensiamo subito a un errore del software, ma la parola è molto più antica.

Nell’inglese medievale, “bugge” indicava un mostro o uno spauracchio, il classico “babau” usato per spaventare i bambini.

Il termine si registra già nel XIV secolo, ad esempio nelle traduzioni bibliche attribuite a John Wyclif, dove bugges indica proprio questi spauracchi.

Già dal Seicento si associa anche ad alcuni insetti (come le cimici da letto), probabilmente per l’idea di una presenza fastidiosa, nascosta o irritante.

Nel 1878 Thomas Edison usa bugs per indicare “piccoli difetti e difficoltà” nei suoi apparati elettrici; da fine Ottocento il termine entra stabilmente nel gergo dell’ingegneria per descrivere guasti misteriosi nelle macchine: da lì ai computer il passo è stato breve.

Grace Hopper lavorava con quel gruppo e rese celebre l’episodio: la parola bug circolava già tra gli ingegneri ma quella falena è stato il primo caso fisicamente documentato dentro un computer con tanto di prova incollata sul diario.

Cosa significa “avere un bug”

In informatica quando diciamo che un programma “ha un bug” intendiamo che contiene un difetto (un baco) che lo porta a funzionare in modo diverso da quanto previsto.

Può essere un errore di progettazione o di programmazione, un’anomalia nel codice o nell’hardware, che si manifesta con risultati errati, funzioni che non si attivano, crash o rallentamenti.

Per estensione, “avere un bug” è entrato anche nel linguaggio comune indicando qualcosa che non va, un problema che “disturba” e che richiede di essere analizzato e, se possibile, “debuggato”, o risolto, se preferisci.

Come si formano i bug

I bug non spuntano dal nulla: nella maggior parte dei casi nascono dall’incrocio tra errore umano e complessità del software.

Uno sviluppatore può sbagliare una logica, dimenticare un caso limite o scrivere una riga di codice errata; se in più i requisiti sono vaghi o cambiano spesso, il rischio di introdurre difetti “invisibili” cresce.

A questo si sommano librerie esterne, differenze tra ambienti (sviluppo, test, produzione), configurazioni sbagliate e aggiornamenti che risolvono un problema ma ne creano altri: le famose regressioni.

Sostanzialmente, come in un viaggio, ogni punto del ciclo di sviluppo è un potenziale momento in cui un bug può nascere o sfuggire ai controlli.

L’impatto dei bug

L’impatto dei bug non è solo fastidio: può fermare sistemi, bloccare servizi essenziali e incidere pesantemente sui conti.

Nel solo settore delle telecomunicazioni europee, l’ultimo rapporto ENISA (European Union Agency for Cybersecurity) sulle grandi interruzioni stima che nel 2024 ci siano state circa 1,74 miliardi di ore di disservizio di cui 548 milioni legate a guasti di sistema e 142 milioni attribuite specificamente a bug software.

Su scala globale, il report The hidden costs of downtime di Splunk e Oxford Economics calcola che i downtime dei sistemi digitali costino alle aziende del Global 2000 circa 400 miliardi di dollari l’anno. Il costo medio totale legato al downtime per azienda europea è stimato in 198 milioni di dollari.

Secondo lo stesso studio, il 44 % degli incidenti di downtime è causato da problemi applicativi o infrastrutturali come bug o errori di configurazione.

I tipi di bug

Per orientarsi nel mondo dei bug è utile sapere che non esiste una classificazione “ufficiale” ma alcune categorie tornano con una certa frequenza nella pratica quotidiana di chi sviluppa software.

Alcuni bug riguardano il modo in cui è scritto il codice, altri come i moduli dialogano tra loro o come il programma reagisce agli input e all’ambiente.

Ecco i principali tipi di bug che si incontrano nello sviluppo software, spiegati in modo semplice:

• bug di sintassi
  Il codice è scritto con simboli, parentesi o parole chiave sbagliate rispetto alla sintassi del linguaggio. Di solito il compilatore o l’interprete li blocca subito.
• Bug logici
  L’algoritmo o le condizioni sono errate: il programma gira, ma prende decisioni sbagliate, entra in loop infiniti o restituisce risultati diversi da quelli attesi.
• Bug aritmetici (o di calcolo)
  Errori nei calcoli: overflow, arrotondamenti errati, errori di arrotondamento in virgola mobile o formule implementate male che portano a risultati numerici sbagliati.
• Bug di interfaccia / integrazione
  Nascono quando moduli, API, microservizi o sistemi esterni non “parlano la stessa lingua”: formati dati incompatibili, parametri mancanti, contratti d’interfaccia violati.
• Bug funzionali
  Una funzione non fa ciò che dovrebbe secondo requisiti o specifiche: il tasto “Salva” non salva, il carrello non si aggiorna, il filtro non applica i criteri scelti.
• Bug visuali / di UI
  Il software funziona ma “si vede” che qualcosa non va: elementi sovrapposti, testi tagliati, layout rotti, problemi di responsive design.
• Bug di performance
  Quando l’applicazione è troppo lenta, consuma risorse in modo anomalo o va in timeout/crash sotto carico. Rientrano qui colli di bottiglia, query pesanti, memory leak.
• Bug di sicurezza
  Difetti che aprono vulnerabilità: validazioni mancanti, injection (come SQLi), problemi di autenticazione/autorizzazione, o difetti sfruttabili per la manipolazione della memoria.
• Bug di compatibilità
  Il software funziona in un ambiente ma non in altri: browser diversi, sistemi operativi, risoluzioni, versioni di librerie o device specifici.
• Bug boundary / out-of-bounds
  Spesso sono la base di vulnerabilità critiche come il buffer overflow. Si verificano quando il programma accede a dati fuori dai limiti previsti (es. indice di array fuori range, input troppo lungo o di tipo inatteso).
• Bug di concorrenza
  Difetti che emergono solo con più thread/processi in parallelo: race condition, deadlock, aggiornamenti non sincronizzati che producono stati incoerenti.
• Bug di configurazione / ambiente
  Non dipendono dal codice in sé ma da parametri, variabili d’ambiente, permessi, versioni di librerie o differenze tra sviluppo, test e produzione. In DevOps si parla spesso di environment mismatch o di configuration drift per descrivere queste situazioni.
• Bug di unità vs bug di sistema
  Un bug di unità è confinato a una singola funzione/modulo (spesso un errore di logica o calcolo); un bug di sistema emerge solo dall’interazione tra più componenti o servizi.

Perché si dice “buggato”

In italiano si dice buggato perché abbiamo preso l’inglese bug e l’abbiamo “italianizzato” seguendo uno schema ormai tipico del linguaggio digitale: bug → buggare → buggato.

Come spiegano Treccani e l’Accademia della Crusca, bug indica un errore di programmazione; da qui nascono il verbo colloquiale buggare e il participio buggato, che – nelle parole della Crusca – significa “che non funziona a causa di qualche errore di programmazione”.

Prima si usava quasi solo per software e videogiochi (“il gioco è buggato”), poi il gergo dei gamer l’ha portato nel parlato comune: oggi può essere “buggato” anche un sito, uno smartphone… o scherzosamente “il cervello”, quando ci sentiamo in tilt.

L’uso nel linguaggio comune si è diffuso negli anni 2000 con l’esplosione di videogiochi e dei social media.

Esempio di bug

Il guasto informatico di CrowdStrike del 19 luglio 2024 è un esempio moderno e drammatico di come un bug possa avere conseguenze globali.

Un aggiornamento di configurazione difettoso (“Channel File 291”) per il software di sicurezza Falcon causò una lettura fuori dai limiti della memoria sui computer client, portandoli a un crash immediato (il cosiddetto “Blue Screen of Death”).

L’impatto fu sistemico: furono colpiti aeroporti (con 6.855 voli cancellati nel mondo), ospedali, banche, servizi di emergenza e reti televisive. Delta Air Lines ha stimato perdite per circa 500 milioni di dollari e ha avviato un’azione legale contro CrowdStrike e Microsoft per ottenere un risarcimento.

La risoluzione del problema ha richiesto interventi manuali su un grande numero di sistemi e in molte organizzazioni i disservizi si sono protratti per giorni.

Oltre agli enormi costi economici e di reputazione per i brand coinvolti, l’episodio ha insegnato all’industria tecnologica l’importanza cruciale di test rigorosi, rollout graduali degli aggiornamenti e piani di disaster recovery per mitigare i “single point of failure”.