Progettare, sviluppare e mantenere software è un lavoro complesso. Uno dei lavori più stressanti a mio avviso, che con l’avvento del mainstream computing ha portato la percezione di come sia “semplice” fare le cose con il computer.

La realtà è però molto diversa. Soprattutto nel caso si debba garantire un’ottima user experience, il sottostante sarà dannatamente complicato. Siamo abituati ad avere a che fare con trappole per umani come Facebook, Youtube, Instagram e gli altri social network, curati in ogni dettaglio per farci restare a nostro agio nella loro piattaforma. Siamo abituati alla semplicità di Gmail, all’intuitività di Apple e alla comunicazione in tempo reale via Whatsapp.

Quello che banalmente poteva essere un semplice sito web degli anni ‘90 / 2000, ora è un disastro di complessità, che non viene mai percepita. “Ma tanto ci metti 5 minuti col computer” è una delle frasi più odiose, insieme ovviamente all’immancabile “lo sa fare anche AMMIOCUGINO”.

Esperienza a parte, fondamentale per la corretta realizzazione di progetti complessi, l’information technology in generale è un lavoro di testa e il nostro cervello, seppur fantastico, a volte si lascia ingannare e prende delle scorciatoie.

Sono veri e propri errori di ragionamento, note anche come fallacie. Per evitarle è necessario conoscerle. Cerchiamo quindi di vedere le principali nel campo del software engineering. Io ne conosco 5. Se ne conoscete altre scrivetemi che le aggiungiamo alla lista.

Fallacia del nirvana

La ricerca della soluzione perfetta. Si prende una soluzione ideale ad un problema e la si compara con una soluzione reale e praticabile. Quest’ultima viene scartata perché non perfetta.

Ogni sviluppatore software / analista vorrebbe mettere in pratica la migliore soluzione per un problema ma questo a volte si scontra con la realtà delle deadline e delle risorse disponibili.

Una soluzione è passare dalle pratiche perfezionistiche a progettazione uniforme in tutte le sue componenti, all’introduzione di metriche misurabili, di logging accurato e multilivello e alla gestione dell’ordinario (principio di pareto, anyone?).

Fallacia dello storico

L’idea che chi ha preso decisioni in passato l’abbia fatto con la stessa prospettiva e il contesto di coloro che attualmente stanno analizzando la stessa situazione.

Certo a volte può capitare che il codice e il design siano orrendi ma non è sempre a causa di cattivi ingegneri del software. Spesso le decisioni sono prese per il contesto dell’epoca, perché magari non c’era il tempo necessario o i requisiti erano mutevoli (più del dovuto).

Fallacia degli sopravvissuti

“La storia è scritta dai vincitori.”
“I morti non raccontano storie.”

Queste due citazioni sono esattamente il succo di questa fallacia. Un piccolo numero di successi ci fa dimenticare un’enormità di fallimenti. Ricordate sempre che per qualche unicorno, portato come esempio di eccellenza, esistono migliaia di vittime lungo il percorso, delle quali non conosciamo generalmente nulla, o poco.

Questo è in particolare da ricordare nel campo degli investimenti e delle start-up. Potete fallire, come è successo a tanti (anche a me) e succederà ancora.

Appello all’autorità

Si ritiene corretta un’affermazione solo per il fatto che è stata pronunciata da una persona in una certa posizione di autorità. Ovvero, si giustificano le proprie decisioni sulla base di quanto detto da qualcun altro che viene considerato esperto.

Sebbene sia corretto affidarsi agli esperti, non va mai preso come oro colato il loro approccio nel design / sviluppo di software. Google è l’esempio perfetto. Ricordate clojure? Ecco, era una ciofeca ed è ora un progetto morto, eppure tantissimi sono caduti nella trappola :)

Gli approcci corretti vanno sempre verificati e man mano che guadagnerete esperienza riuscirete a distinguere le intuizioni corrette e le best practice.

Chiarezza fuorviante (misleading vividness)

Prendere un ristretto campione di eventi molto significativi per impatto al fine di minimizzare l’evidenza statistica.

Questa fallacia è un atto di self-awareness. Piuttosto di ammettere di aver sbagliato o di essere scarsi in un certo settore si cominciano ad accampare scuse tecniche o dettagli non necessari.

Chi sbaglia sicuramente non vuole mettersi alla berlina, tuttavia è importante per il project manager di considerare sempre il contesto e come ottenere un risultato, auspicabilmente positivo, da ogni situazione. Le chiacchere stanno a zero.

Può essere applicato anche al contesto emozionale. Ad esempio è alla base di “Oggi c’è freddo quindi non esiste il riscaldamento globale”.