Ieri sera ho partecipato alla cena DDD organizzata in Managed Designs, è stata
una piacevole serata in cui abbiamo fatto quattro chiacchiere sulla nostra amata professione.
Si sono toccati molti argomenti non solo il DDD.
C'è un punto emerso tagliando una gustosa cotoletta che mi piacerebbe approfondire qui: l'incertezza intrinseca del nostro mestiere.
Fare previsioni affidabili è una necessità, prima di tutto economica, perchè i budget si devono organizzare prima
e perchè il progetto sia redditizio per chi lo sviluppa.
Una cosa che ci viene naturale come essere umani è quella di cercare di incanalare il progetto in un binario già noto
da cui il nascere di definizioni come l'applicazione è datacentrica, gestiamo tutto nel modo x, ecc. Si cerca cioè
di proiettare nel futuro una cosa già vista nel passato (si chiama ragionamento induttivo, leggetevi la storia del tacchino
su questo articolo di wikipedia).
Questa logica soffre IMHO di alcune debolezze. Se ho commesso un errore nel passato di cui non sono consapevole
lo commetterò di nuovo nel futuro. Inoltre in questo modo sono tendenzialmente chiuso a provare strade nuove perchè
non conoscendo a priori il risultato temo che sarà peggiore.
Ed è proprio questo secondo me quello che si chiama paura e dove ci vuole coraggio.
Un altro luogo comune che vorrei sfatare è: più tempo dedico a fare una stima, migliore sarà la stima. Risponderò
a questo con un esperimento che è stato fatto su due gruppi di persone. Ad entrambi i gruppi veniva mostrato
una fotografia sfuocata di un idrante, al primo si passava alla versione non sfuocata in dieci passi, mentre al secondo
in cinque.
Nel momento in cui entrambi i gruppi vedevano la stessa immagine si chiedeva di dire cosa c'era nella fotografia.
Ebbene il gruppo che aveva visto meno immagini rispondeva molto più velocemente. Cosa significa questo?
Se si hanno più informazioni si devono valutare molte più alternative e si rischia di scambiare il rumore per informazione utile.
Come possiamo quindi mitigare, visto che non si può eliminare, l'effetto dell'incertezza?
Tenendo conto di alcuni fattori. Primo: l'effetto delle previsioni degrada velocemente nel tempo, cioè pianificare la
prossima settimana è più facile che pianificare i prossimi due mesi. Secondo: Non si può sapere a priori quali siano gli eventi
che cambieranno il piano che abbiamo fatto e quindi occorre essere sufficientemente flessibili da permettere il cambiamento.
Come raggiungere il secondo obiettivo? Un modo è quello di gestire tutto il progetto come se i tutti i requisiti fossero
frutto di un cambiamento. In questo modo l'architettura diventerà sufficientemente malleabile da accettare più facilmente
i cambiamenti.
Lo scopo di questo post è fornire spunti di riflessione non quello di dispensare ricette precotte che vi faranno diventare
ottimi sviluppatori in 28 giorni. Non esistono soluzioni semplici
per affrontare la complessità e il cambiamento, ma IMHO ci sono modi che funzionano meglio di altri.
Se vi interessa approfondire l'argomento vi consiglio la lettura del libro:
The Black Swan.