Pur non essendo programmatore, mi trovo sempre piu spesso (per passione o per lavoro) a scribacchiare codice, soprattutto in fase di prototipazione. Il bugfencing è una tecnica di programmazione utilizzata proprio in questo specifico momento del ciclo di vita di un software e consiste sostanzialmente nel mantenere i bug e sfruttarne la presenza al fine di ottenere nuove features.

L’ambiente di sviluppo ideale per il bugfencing è preferibilmente di alto livello (applicativi flash o ajax, grammatiche polygen o aiml, scripting MEL o LSL) . Pensiamo per esempio a Flash: flash è un ottimo ambiente per realizzare prototipi; inoltre la possibilità di affiancare scrittura di codice e editing WYSIWYG e l’immediata visibilità del risultato creano le condizioni ideali per la proliferazione e il mantenimento dei bug.

Iniziamo con una case study abbastanza nota: Matrix.

The first Matrix I designed was quite naturally perfect, it was a work of art, flawless, sublime. A triumph equaled only by its monumental failure. The inevitability of its doom is as apparent to me now as a consequence of the imperfection inherent in every human being, thus I redesigned it based on your history to more accurately reflect the varying grotesqueries of your nature. However, I was again frustrated by failure. I have since come to understand that the answer eluded me because it required a lesser mind, or perhaps a mind less bound by the parameters of perfection. Thus, the answer was stumbled upon by another, an intuitive program, initially created to investigate certain aspects of the human psyche.
[The Matrix Reloaded]

Con queste parole l’Architetto di Matrix spiega a Neo l’esigenza di un approccio progettuale non-logico al fine di migliorare il proprio software. Ecco cosa si evince dalle enigmatiche frasi:
1) Il fallimento delle prime Matrix dipende dal cattivo design della user experience e non da problemi di programmazione
2) La soluzione giunge da una mente meno vincolata a parametri di perfezione
3) La soluzione giunge per caso
4) L’architetto è probabilmente un designer e l’oracolo uno psicologo (cognitivo?)

Perchè una mente troppo vincolata a parametri di perfezione non è in grado di giungere alla soluzione? La risposta è semplice: un approccio eccessivamente logico difficilmente farà scoperte per caso.
lo stesso de Bono ci ricorda, tra l’altro, come il concetto stesso di ’scoperta fatta per caso’ sia errato in partenza, frutto di una cultura troppo legata all’approccio logico-deduttivo: il ‘caso’ mette in continuazione davanti ai nostri occhi la soluzione a centinaia di problemi, ma è poi compito nostro scovare le risposte e riconoscerle come tali. Al posto di Fleming, un altro ricercatore avrebbe gettato tra i rifiuti il campione di coltura batterica ‘rovinato’ senza così compiere il primo passo verso l’isolamento della penicillina. Da questo presupposto nasce il bugfencing.

Ma torniamo alla case study:
Il problema non era nel codice, ma nelle features di Matrix, che risultavano incompatibili con le aspettative del target d’utenza. L’introduzione nel Sorgente di Matrix di un’anomalia (un bug) risolve questa issue progettuale, con una coraggiosa decisione da parte del team di sviluppo che opta per una migliore user experience a discapito della stabilità del sistema.

Che cos’è un bug?

A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result). [da wikipedia]

Il concetto di bug fixing, cioè l’idea che un comportamento differente da ciò che ci si aspetta sia per definizione errato e che la sua causa vada cercata ed eradicata, ricorda il modus operandi degli inquisitori: profondamente violento e culturalmente antievoluzionista.
Il bugfencing è una sorta di eresia informatica, è la negazione di questo modus operandi, è la non eliminazione del bug unita alla sua trasformazione in feature.

Il termine letteralmente significa ’schermare con i bug’.
La scherma, nella sua più antica (non sportiva) accezione, era una forma di difesa armata, uno ’schermo’ contro il nemico; e come ogni arte marziale che si rispetti, anche la scherma tradizionale è costellata di tecniche per sfruttare la forza del nemico contro di lui. Ed ecco l’idea del bugfencing: usare la ‘forza’ del bug a proprio vantaggio.

In realtà il concetto è un pò più “raffinato” e parte dall’idea che dietro ad ogni problema si celi un’opportunità; o, ancora meglio, che non esistano problemi, ma solo opportunità. Quando si sviluppa un software il bug arriva per caso: è il risultato di un errore, come la muffa su una coltura batterica, e il bugfencer deve saperne cogliere il potenziale, deve trovarci la penicillina. Un comportamento inaspettato va accuratamente osservato, se necessario isolandolo dal contesto: forse non avrà nulla a che fare con il software che si sta sviluppando, ma si tratta comunque di una novità che, magari, potrebbe anche tornare utile in futuro o servire da spunto per altre idee.

Basti pensare al dna: il dna è un codice.
La riproduzione sessuata è difficile, pericolosa e sporca; perchè allora la natura si è impegnata così tanto a renderla estremamente piacevole? Perchè sottrarre tempo alla ricerca di cibo e mettersi maggiormente in luce agli occhi dei predatori attraverso una pratica scomoda come la riproduzione sessuata? Perché è evolutivamente vincente: aumenta il caos, aumenta le probabilità di mutazioni e quindi aumenta il potenziale evolutivo. Ciò che evolutivamente si chiama mutazione, può essere informaticamente inteso come bug. Il bugfencing sta quindi alla programmazione standard come la riproduzione sessuata sta alla mitosi. E come lo scopo della riproduzione sessuata non è quello di generare nuovo dna, ma di produrre il cambiamento, così l’obiettivo del bugfencing non è la produzione di codice, ma la realizzazione di nuove features. L’uso del bugfencing in fase di produzione sarebbe infatti estrememente rischioso, vista l’imprevedibilità legata a questa tecnica. L’aumento di instabilità di un software non va esattamente a braccetto con le logiche di mercato (almeno in teoria).

Il bugfencing è una tecnica da utilizzare quando la stabilità di un software non è richiesta, quando è essenziale che il software muti ed evolva: il bugfencing raggiunge la sua massima espressione nella prototipazione.
Tanto più il progetto è ‘giovane’, quanto più le nuove features potranno esservi integrate. Man mano che il progetto si definisce, infatti, i comportamenti anomali del software tendono ad essere ignorati o scartati, mentre all’inizio della sua esistenza, quando anche i suoi stessi obiettivi non sono ancora del tutto chiari, l’errore generato dal caso diviene fonte di ispirazione, il prototipo diventa esso stesso interlocutore di chi sviluppa il prototipo, i suoi comportamenti inaspettati che derivano dal mantenimento dei bug sono ottimi spunti per l’implementazione di nuove features.
Fare bugfencing durante la definizione di un concept è come fare brainstorming con il destino.