“Trial and error”: non è una metodologia di sviluppo!

In ambito scientifico il “trial and error” è un modo di procedere certamente molto umano, l’applicazione pratica dello “sbagliando s’impara“.

Partendo da poche o scarse informazioni su un qualcosa, se ne possono acquisire analizzandolo e, nel caso sia possibile, utilizzandolo. Un po’ come quando ci si trova per le mani un prodotto sconosciuto e con molta cautela si prova ad usarlo per capire come funziona, magari modificando qualche dettaglio (l’amico Cavok parlerebbe di “girare un manopolino”) ad ogni giro ed individuare se e cosa cambia.

Ma questa “strategia” ha comunque delle serie limitazioni in altri casi e non è sempre applicabile con profitto.

Imparare dagli errori

Da Wikipedia:

Trial and error, or trial by error, is a general method of problem solving, fixing things, or for obtaining knowledge. “Learning doesn’t happen from failure itself but rather from analyzing the failure, making a change, and then trying again.”

In the field of computer science, the method is called “generate and test“. In elementary algebra, when solving equations, it is “guess and check“.

This approach can be seen as one of the two basic approaches to problem solving and is contrasted with an approach using insight and theory.

La definizione di Wikipedia rende molto bene l’idea, specialmente nel punto in cui parla di “guess and check“: è una tecnica di procedere certamente efficace per quanto un po’ grezza.

Partendo dall’ignoto e tentando di decifrarlo, ha senso tirare a caso e controllare cosa è cambiato, ma quando si parte con qualcosa di definito e noto, questa strategia si rivela altamente inefficiente e controproducente.

Sempre da Wikipedia:

Trial and error is usually a last resort for a particular problem, as there are a number of problems with it. For one, trial and error is tedious and monotonous. Also, it is very time-consuming; chemical engineers must sift through millions of various potential chemicals before they find one that works. There is also an element of risk, in that if a certain attempt at a solution is extremely erroneous, it can produce disastrous results that may or may not be repairable.

Il trial and error non è una metodologia di sviluppo e di gestione dei rilasci!

Fermo restando che in ogni lavoro c’è sempre una componente nuova, imponderabile e rischiosa con cui avere a che fare, non si può utilizzare il “trial and error” come una metodologia di sviluppo in senso stretto.

A meno che il proprio lavoro, ad esempio, non sia puro “reverse engineering” oppure tocchi fenomeni ignoti o non ancora del tutto compresi. Sempre da Wikipedia:

Nuclear weapons are in large part designed by trial and error. The trial often involves test explosion of a prototype.

Nel caso si parli di sviluppo non si può buttar giù codice un po’ a caso, vedere se più o meno fa quello che serve, rilasciare il tutto come prodotto finito e poi limitarsi a correggere pedissequamente i vari bug che emergono senza rivedere e correggere le eventuali deficienze strutturali del progetto.

Questo non è sviluppo e gestione dei rilasci e non ci si salva parlando di strategia “tipo trial and error“! Non c’è davvero scusa che tenga, almeno non sul medio-lungo periodo. Può garantire un po’ di respiro mentre si risolve davvero un problema, ma solo temporaneamente. Di sicuro aI clienti le soluzioni temporanee non piacciono proprio.

Se correggere un bug e rilasciare immediatamente una patch ai clienti è cosa buona e giusta (“serietà”), non lo è altrettanto dedicarsi solamente a fixare bug su bug dopo il rilascio senza investigare se ci sia dell’altro a monte che generi tutti questi problemi, magari un design errato di qualche componente.

D’accordo, in certi casi non si può proprio riscrivere una porzione cospicua di codice mal progettato perchè troppo rischioso, ma almeno si può marchiarlo come pericoloso (“// hic sunt leones“) e “da sostituire” preferibilmente in una major release successiva o comunque appena possibile.

Anche se, volendo essere corretti e pignoli, è sempre preferibile sistemare subito i problemi, non limitarsi semplicemente a segnalarli nel codice per una futura correzione. Da The Elements of Programming Style, di B. Kernighan e P. J. Plauger:

“Don’t comment bad code, rewrite it.”

Il vero problema

Chiariamo bene un punto: rilasciare qualcosa e limitarsi a correggere i bug senza indagare oltre non è solo un subdolo “trial and error” mascherato da “bug-fixing serio“, ma è anche e sopratutto un “voler far recitare ai clienti il ruolo dei betatester“. Un errore clamoroso!

Non ci si limita a tappare ogni buco o a stuccare sistematicamente ogni crepa in una diga costruita di fretta senza mai fermarsi un attimo e chiedersi se a furia di rattoppi prima o poi crollerà in blocco. Nè ci si limita a sistemare le cose in maniera posticcia e temporanea (“per ora va bene così”) per poi dimenticarsi di fare le cose per bene ed in modo definitivo.

Eppure, nonostante tutto, molta gente è tuttora convinta che procedere sviluppando, correggendo o modificando di volta in volta il solo minimo indispensabile sia un buon modo di lavorare. Oppure, ancora peggio, si trincera dietro alla patetica scusa del “ho sempre fatto le cose così ed è sempre andata bene“: per favore, confidare solamente nella fortuna non è un metodo di lavoro, neppure per i professionisti dei giochi d’azzardo!

Parlando di programmazione, vale la pena citare Spolsky:

Programmers seem to have stopped reading books. The market for books on programming topics is miniscule compared to the number of working programmers.

Instead, they happily program away, using trial-and-error. When they can’t figure something out, they type a question into Google.

Sarà la mia esperienza ma l’unica cosa che ho notato è che il “trial and error“, applicato sia durante lo sviluppo che dopo il rilascio, è solamente un buon modo per farsi male, per non concludere mai i lavori e per dare ai clienti l’impressione di aver venduto loro qualcosa di inaffidabile e mal progettato. E quando un cliente inizia a sentirsi preso in giro…

Sfortunatamente serve un discreto tempo (ed una sfilza di buoni prodotti) per guadagnarsi la fiducia ed il rispetto della clientela ma basta davvero poco a perderla: deve essere un nostro limite umano dimenticare in fretta i successi ma ricordarci benissimo ed in modo duraturo qualcosa che è andato storto.

Chiariamo un altro punto: premettendo che sbagliare è umano e porre rimedio in fretta alle proprie mancanze è doveroso, un’azienda è tanto più seria quanto meno difettosi sono i suoi prodotti non solamente quanto meno tempo ci mette a fixare i suoi bug. Come dire: reputo più seria un’azienda che mi vende un prodotto con pochi problemi di una che me ne vende un altro con molti, anche se ci mette poco a correggerli.

La competizione si fa sulla qualità dei prodotti e poi complessivamente sul servizio offerto alla clientela, non solo sull’assistenza e/o sulla celerità di risposta in caso di problemi (anche se lo sappiamo tutti l’assistenza è una macchina da soldi, almeno quella a chiamata ossia non forfettaria).

Dopotutto, se vi siete trovati (molto) bene con una certa marca, non continuereste a comprarne i prodotti (e a parlare bene di essa)?

Che ne pensate?