Anche i Big hanno i Bug

Cos’è un bug?

Cerco di spiegartelo con un esempio: ti è mai successo di utilizzare un oggetto come una penna o una macchinetta del caffè a cialde (qualsiasi oggetto per capirci) e riscontrare problemi durante il suo utilizzo? Qualcosa di andato storto, di inaspettato o che in sua mancanza o inefficienza ti ha portato un disagio?

Ecco, questo è un bug.

Non tutti sono bug

Ho un’altra domanda per te, concedimela.

Nello stesso momento dell’uso degli stessi strumenti sopra menzionati, ti è mai capitato di pensare che avere una funzionalità o qualcosa di “in più” avrebbe migliorato la tua esperienza, esistenza o vita? Esempio avere una macchina del caffè auto-pulente, una penna che si sa chiudere da sola?

Ecco, questo invece è considerabile Change Request.

Ti starai chiedendo cosa sono e cosa c’entra il titolo di questo articolo con questa intro un po’ stravagante ma a breve ci arriverò.

Prima di procedere però permettimi di presentarti un paio di oggetti che utilizzeremo come esempio lungo tutto l’articolo, che in realtà già conosci:

• Oggetto n°1: una macchinetta del caffè a cialde di quelle che fanno appunto solo il caffè, della marca che vuoi, senza sponsorizzare nessuno (per essere più chiari: apro, metto cialda, riempio acqua, premo bottone, si scalda e esce il caffè);

• Oggetto n°2: una penna biro, di qualsiasi tipo e colore (a me piacciono le nere) di quelle a scatto senza tappo con una “clip” per attaccarla a fogli, taschini o cartelline (le penne che premi per aprire e premi per chiudere, sempre per essere molto chiari);

Bene, abbiamo i nostri due oggetti, ti ho detto brevemente cosa è un bug e cosa una change request e quindi: possiamo iniziare.

Cosa si intende per bug

Probabilmente avrai già sentito questa parola: “bug”.

Se non l’hai mai sentita prima di questo articolo, l’hai comunque sentita poco sopra, per cui è bene che tu sappia cosa significa veramente, da dove proviene e anche come è stata “inventata”.

Cito testualmente Wikipedia che spiega in poche righe cosa è un bug in modo molto chiaro:

Il bug, nell’ambito della programmazione software, è un guasto che porta al malfunzionamento del software (per esempio producendo un risultato inatteso o errato), tipicamente dovuto ad un errore nella scrittura del codice sorgente di un programma software scritto da un programmatore.

Un programma contenente un gran numero di bug che interferiscono con la sua funzionalità è detto buggato (in inglese buggy), mentre l’atto di correzione degli errori è detto bugfixing.

Un bug è quindi un malfunzionamento di un sistema, normalmente solo in ambito digitale poiché è nato proprio in questo contesto.

Si narra infatti che agli albori dell’informatica, in un normalissimo giorno di Settembre del 1947, la tenente Grace Hopper ed il suo team di ingegneri stavano cercando la causa del malfunzionamento di un computer quando, con stupore, si accorsero che una falena si era incastrata tra i circuiti.

Da li registrarono in un report il termine “bug” (insetto in italiano o più precisamente “baco”) come motivo del malfunzionamento e da quel giorno è utilizzato nell’ambiente del software come identificazione generale di ogni malfunzionamento.

In realtà ci sono cenni di questo termine anche molto più indietro, addirittura nel 1870 con Edison ma, al netto di ogni verità ora sai cos’è un bug, perché si chiama così e la prossima volta che ne parlerai con qualcuno avrai una storia interessante e molto divertente da raccontare 🙂

Un esempio di bug

Ti ricordi della macchina del caffè a cialde e della penna?

Beh, per prendere esempi “fisici” e farti capire in modo molto semplice cosa potrebbe essere un bug in uno di questi due oggetti potrei raccontarti queste due storie:

• Macchinetta del caffè: attacchi la spina, accendi la macchinetta, metti l’acqua, inserisci la cialda, la luce si ferma, premi per far uscire il caffè e… non succede nulla. Hai riscontrato un malfunzionamento che potrebbe essere causa di qualcosa che hai fatto tu di sbagliato (ma sai di aver fatto tutto per bene) oppure di un problema della macchinetta stessa. Hai individuato un “bug”;

• Penna biro: la sbusti, la apri (nel senso che esce la punta), la impugni, inizi a scrivere e…. (indovina?) non scrive. Provi a scaldarla nei modi più disparati (ho notato negli anni che ognuno ha il suo) pensando che è l’inchiostro freddo (probabilmente una leggenda metropolitana) ma il problema è che la punta è rovinata e non scrive. Altro bug.

Individuare un bug è, almeno per me, un’esperienza che è a metà tra il frustrante (non funziona, non riesco a fare quello che vorrei) e l’eccitante (t’ho “sgamato” mio caro ingegnere/sviluppatore, eh?).

Il punto è che un bug, per quanto sia facile individuarlo nel momento in cui si usa il prodotto (una penna, una macchinetta o un prodotto digitale) è spesso molto complesso da anticipare.

Durante le fasi di progettazione, di sviluppo e realizzazione, di testing e di “stressing” (quando i prodotti, digitali o non, vengono messi sotto stress appunto per individuare problematiche prima di metterle in vendita al pubblico) si identificano moltissime problematiche che vengono risolte pre-lancio.

Per quanto tempo, sforzi ed energie si possano dedicare a questa spasmodica ricerca del bug perduto, non si trovano mai tutti. La motivazione è semplice: è matematicamente impossibile mappare ogni caso d’uso, per ogni utente e per ogni condizione.

Questo significa che il concetto di bug è intrinseco nel concetto di prodotto.

Chiaramente è responsabilità del team che realizza il progetto far sì che il prodotto digitale o fisico vada a mercato con meno bug possibili, ma proprio per definizione ci sarà qualcosa che non andrà e che qualche utente troverà.

Ma se individui un bug, cosa devi fare?

Niente panico: segnalalo al team competente e loro sapranno cosa fare.

Segnalare i bug è “facile, risolvere un po’ meno

Il tuo compito, se vuoi contribuire a far sì che altri come te non inciampino nel bug da te individuato, è quello di segnalare al team competente.

Potresti essere un utente del prodotto (noi che facciamo il caffè o usiamo la penna) e quindi scrivere all’assistenza dei due brand per raccontare cosa ti è successo (o non è successo) oppure potresti essere parte del team che offre il prodotto (per capirci dal lato di chi vende la macchinetta o la penna), per il quale vale lo stesso discorso: segnalare.

Segnalare un bug è una cosa abbastanza semplice ma assicurati di dare quante più informazioni possibili se puoi: per poter trovare e sistemare un bug, questo va riprodotto per analizzarlo.

Così come è semplice segnalare un bug, andarlo a risolvere non è poi così semplice.

Potrebbe trattarsi di un bug evidente, “di superficie”, per il quale a prima vista ci si rende conto del problema o del malfunzionamento oppure qualcosa di più insidioso o di più complesso da trovare.

Ti basta pensare che un prodotto digitale potrebbe essere composto da decine di migliaia di righe di codice e un bug potrebbe essere anche solo la presenza o l’assenza di un punto in queste migliaia di righe (come anche macchina del caffè immagino sia composta da decine di pezzi e pezzetti incastrati tra di loro).

Un prodotto digitale che si rispetti viene testato in primis per scongiurare un bug, ma anche predisposto per far sic he la loro ricerca quando vengono segnalati sia facile e puntuale. Molte volte è semplice, molte volte no.

Bug: una questione di priorità

Ipotizziamo che il prodotto sia stato lanciato sul mercato e che nel primo periodo ci sono molte segnalazioni di bug: alcuni saranno facilmente risolvibili, altri meno, altri molto complessi anche solo da riprodurre per analizzare cosa è successo perché si verificasse un bug.

La cosa più importante è quella di saper dare la giusta priorità alle cose.

La questione è molto semplice e uso i due esempi di prima:

• Bug n°1: il bug evidenzia che c’è “qualcosa” che non fa uscire il caffè. La funzione principale viene meno, il bug è prioritario e molto urgente;

• Bug n° 2: il bug evidenzia che c’è “qualcosa” che fa consumare più acqua del previsto. Un bug certamente, ma il caffè te lo puoi comunque bere, per cui non prioritario;

• Bug n° 3: il bug evidenzia che c’è “qualcosa” che quando esce il caffè fa un brutto rumore. Il caffè esce e il rumore è solo fastidioso, non da nessun tipo di problema tecnico. Un bug certamente ma meno prioritario degli altri quasi sicuramente.

Certo che però ci vorrebbe…

Esiste anche un’altra entità che spesso viene etichettata come bug (ora non puoi dire di non sapere cos’è e come si gestisce, ammettilo!) che è invece a tutti gli effetti qualcosa che manca da pianificazione.

Che cosa intendo? Intendo che potresti usare un prodotto e accorgerti che vorresti fare qualcosa ma che quel qualcosa non puoi o non riesci a farlo e – giustamente – ti lamenti come se fosse un malfunzionamento.

Peccato però che quel qualcosa di cui parli non c’è perché non c’è, non perché è rotto, mal-funzionante o mancante.

Non c’è perché non era previsto, perché sarà previsto in futuro o perché semplicemente è una esigenza del singolo e non della maggior parte degli utilizzatori del prodotto.

Per fare chiarezza torno ai due esempi che ci sono tanto cari:

• Macchinetta del caffè: il caffè lo fa perfettamente ma ci vorrebbe proprio un “qualcosa” per scaldare il latte e fare quella bella cremina da cappuccino del bar… non c’è! mi serve! BUG (ora che sai cos’è un bug potresti farne abuso, credimi anche io in passato ne facevo);

• Penna biro: bellissima la penna nera eh (non capisco come si faccia a scrivere con la blu) ma a me serve anche quella rossa, perché non scrive in due colori? mi serve! …BUG!

Gli esempi estremizzati qui sopra evidenziano un esigenza del singolo, o magari anche della maggior parte delle persone, che non era stata pianificata o prevista per il prodotto in uso.

Questa a tutti gli effetti, se segnalata o richiesta, si tratta appunto di una “Change request” ovvero di una NUOVA funzionalità (del tutto nuova o semplicemente qualcosa di aggiuntivo a qualcosa di esistente) che richiede che venga fatta una valutazione con una successiva una integrazione per poterla avere.

Inoltre ci sono CR (Change request) che si possono fare, previa valutazione e integrazione, mentre altre che non si possono fare per svariati motivi: incompatibilità, mancanza di fattibilità, ecc.

Torno al volo sugli esempi per farti capire di che parlo:

• Macchinetta del caffè: mi servirebbe proprio quel “coso” per fare il cappuccino. Si può fare, probabilmente va ri-progettata la macchinetta ma al prossimo lancio potremo averne una che fa questo e altro;

• Penna biro: bellissima la penna però a me servirebbe che funga anche da borraccia. Esigenza interessante, forse un pò particolare, ma probabilmente tecnicamente infattibile.

La differenza tra bug e change request

Per fare un breve recap di quello che ci siamo detti:

• Bug: malfunzionamento del sistema che evidenzia un problema di varia natura rispetto qualcosa che è previsto che ci sia ma che, per qualche motivo, sembra non funzionare (o non funziona davvero);

• Change Request: funzionalità mancante o non prevista (parziale o totale) che potrebbe essere aggiunta al prodotto per migliorarlo e renderlo più completo (quindi precedentemente non prevista e che necessita di essere trattata diversamente da un malfunzionamento, perché non lo è).

Anche i “big” hanno i bug

Arriviamo però al titolo dell’articolo: anche i Big hanno i Bug.

Se hai capito cosa intendo per Bug, come si identificano, il fatto che sono parte naturale di un prodotto e come vengono gestiti, potresti aver capito perché l’articolo ha questo titolo.

Anche i BIG, intesi come grandi prodotti o grandi portali hanno i Bug. Tutti ce l’hanno. Dai più famosi Social network ai portali delle banche, dalle automobili più famose a strumenti per la cucina di tutti i giorni.

Quante volte ti è capitato di usare qualcosa, di avere un problema e di non sapere cosa fosse? A me capita spessissimo sui portali delle banche per esempio oppure su siti web di dubbia provenienza, ma anche con l’automobile (esempio problemi che provengono direttamente dalla produzione con una macchina nuova di zecca) oppure quando “sbusti” la libreria Billy di Ikea e mancano delle viti (e spesso te ne accorgi quando per metà è montata).

Il bug, che per riassumere può essere definito “errore”, è intrinseco nei prodotti perché è UMANO.

Per concludere vorrei lasciarti una storia davvero divertente che probabilmente hai vissuto (se sei nato nello scorso millennio) o forse avrai soltanto letto da qualche parte: uno dei bug più famosi al mondo, il Millennium Bug.

In sostanza, agli albori dei prodotti digitali, dei software e alla nascita di internet, ingegneri di ogni tipo, dai più svegli ai meno brillanti, lavoravano ai propri prodotti con un sistema di gestione delle date, precisamente degli anni (xx/xx/anno) che prevedeva solo due cifre.

Una cosa normale dirai: tutti usano due cifre come ad esempio il 25/12/20. In pochi scrivono 2020 ed è una cosa normalissima abbreviare.

Peccato che i sistemi, nati negli anni 19xx, quindi prima dell’avvento del 2000, erano “tarati” per funzionare appunto con due numeri dove il più alto era 99 e, sebbene sarebbe bastato procedere con un ‘00 per riferirsi all’anno 2000, moltissimi programmi non erano predisposti per farlo in modo conscio.

Questo significa che la maggior parte dei sistemi digitali avrebbe reagito “a modo suo” con potenziali rischi catastrofici. Non si parla ovviamente solo di siti web o cose semplici ma anche di sistemi bancari, aeroportuali, statali, ecc.

Cosa successe? Qualcuno evidenziò il BUG dei bug e orde di sviluppatori e ingegneri dovettero sistemare ogni prodotto digitale e software affinché fosse predisposto a rispondere in modo positivo a questo semplicissimo ma enorme bug.

Se vuoi sapere altro sul Millennium Bug, ti rimando alla pagina di Wikipedia che ne parla.