Il metodo e Popper "questo sconosciuto"
Non ho la volontà (né la capacità) di dissertare di filosofia ma solo di portare una mia breve esperienza.
La prima volta che ho sentito nominare Karl Popper fu all'Università durante il corso di "Storia del pensiero economico" dove fra i primi argomenti trattati si spiega come distinguere ciò che è scientifico da ciò che non lo è. Si trattò per me dell'ultimo esame prima della discussione della tesi e all'epoca già lavoravo da qualche anno nel settore informatico.
Mi resi conto che applicare il metodo scientifico è la base di qualunque altra disciplina, anche dell'Informatica. Ed essendo la base è concetto da insegnare e acquisire per primo; invece, nei primi corsi da matricole si insegnano argomenti dal nome altisonante come la "Teoria Neoclassica della Crescita Economica" e a risolvere equazioni differenziali del prim'ordine, senza spiegare molto su che cos'è una teoria economica, cioè se "stia in piedi realmente" o se sia solo un bell'esercizio matematico.
In breve, ciò che del pensiero di Popper mi è rimasto è il "burrone" che c'è tra verificazione e falsificazione di una teoria scientifica. Sappiamo bene che le osservazioni sperimentali a favore di una teoria, anche se la corroborano, non possono mai provarla definitivamente. La falsificabilità è anche il criterio per discriminare tra scienza e non-scienza: una teoria è scientifica se, e solo se, essa è falsificabile cioè si espone continuamente al rischio di essere confutata.
Nell’ambito professionale come consulente e tecnico informatico tale "burrone" si manifesta non tanto nella fase di analisi e sviluppo, quanto piuttosto nella stesura dei casi di test e nella loro esecuzione per mostrare e garantire che il software che stiamo realizzando o manutenendo sia privo di errori.
La fase di test, l’insieme e potenza dei test sono, secondo me, una delle chiavi che decideono del successo o del fallimento di un progetto informatico.
Stiamo parlando di software sufficientemente complesso dove, nonostante ogni cautela, il bug è sempre in agguato e per il fatto stesso di non essere emerso presto in un test precedente, la sua risoluzione richiede un nuovo test più potente. Non solo: ogni volta che si scopre un bug - triste, ma vero - è statisticamente certo che ce n'è un altro che non è ancora emerso. .
Ma le anomalie più difficili da scovare - che emergono nel momento più inatteso e che fanno tirare mezzanotte per venirne a capo - sono quelle che dipendono dall'ambiente nel quale il tal componente software vive; tipico esempio quando esso funziona perfettamente in uno degli ambienti ma si comporta in modo erratico in un altro che - siamo assolutamente certi - essere configurati in modo perfettamente identico, anomalie che scuotono le fondamenta delle nostre certezze...
Quante volte ho sentito esclamare "Come è possibile?!?"... è da buon popperiano la mia risposta - sommessa e vagamente filosofica - è sempre stata "sono due ambienti differenti, bisogna aguzzare la vista e scovare la differenza"...
