Saturday’s Talks: la complessità del mondo software ci seppellirà, se non impariamo l’empatia

Quando descriviamo negli articoli su MiaMammaUsaLinux le tecnologie che stanno dominando questa fase storica dell’informatica, capita sovente di associare ai loro nomi una parola: complessità. Infatti è innegabile come per quanto le opportunità offerte da queste tecnologie siano pressoché sconfinate è altrettanto vero che la padronanza delle stesse e soprattutto dei progetti che si scelgono di erogare mediante esse, sia molto difficile da raggiungere.

Perché? Perché non si tratta quasi mai di fare doppio click su “setup.exe” ed essere a posto. Nel mondo vero le cose sono un poco più complicate dell’installazione di WinAmp.

Ho letto recentemente questo interessante articolo sulla tematica e ad un certo punto recita:

One thing working in complexity’s favor, though, is that engineers like complexity. Admit it: as much as we complain about other people’s complexity, we love our own. We love sitting around and dreaming up new architectural diagrams that can comfortably sit inside our own heads – it’s only when these diagrams leave our heads, take shape in the real world, and outgrow the size of any one person’s head that the problems begin.

Fate parte anche voi di quel nutrito gruppo di ingegneri che adora la complessità, purché sia solo la propria? È una domanda complicata alla quale rispondere, perché se qualcosa è chiaro nella nostra testa come è possibile definirlo complicato?!

Quali sono quindi i segnali che possono aiutare a riconoscere un progetto (sia questo un software, un’infrastruttura, una pipeline di produzione) complicato?

Ho provato a sintetizzarne tre, nella lista che segue:

1. Un progetto complicato è difficile da man(u)tenere: quando operazioni base che fanno parte del ciclo di vita di un progetto, per esempio un aggiornamento o l’aggiunta di una funzionalità, falliscono spesso, quello è il segnale che la soluzione in questione è troppo articolata. Le implementazioni fatte per durare nel tempo hanno modalità di gestione bullet-proof.
2. Un progetto complicato si disconosce facilmente: vi è mai capitato di dire “eh già, questa schifezza l’avevo creata io nel mio periodo blu”? Ebbene, quello è chiaramente il sintomo che qualcosa non ha funzionato. Se il giorno dopo aver implementato una soluzione ci si chiede come funziona, allora è verosimile che ci sia sovra-complessità.
3. Un progetto complicato viene domato solo da chi l’ha creato: se l’unico a poter agire sul progetto è il suo creatore, c’è qualcosa che non va. Oltre a costituire un pericolo reale per l’azienda che eroga il servizio (cosa succede se il suo creatore vince la lotteria e si trasferisce alle isole Baleari a prendere il sole tutto l’anno?), c’è un problema professionale di fondo, infatti che senso avrebbe costruire macchine che possono guidare solo gli ingegneri ed i meccanici?

E scommetto che ci sono tanti altri segnali da condividere (fatelo nei commenti se volete). Il punto è che ciascuno di noi ha il suo kit per l’identificazione della complicatezza ben chiaro nella testa. È quella cosa che ti fa dire “Ho capito dove vuole arrivare, non fa per me”.

Il problema è che non sempre le cose complicate si possono schivare, e tante volte siamo chiamati in prima persona a condividere il lavoro in modo che altri lo possano capire o che vi possano contribuire.

Quindi come ci si salva quindi? Quale è il segreto da conoscere per evitare di farsi odiare dai posteri e far sì che quanto implementato abbia lunga e felice vita? Anche qui ho provato a sintetizzare tre azioni che si contrappongono alle tre cause presentate sopra:

1. Un buon progetto vive di politiche standard e condivise: standardizzare le procedure di manutenzione del progetto e non renderle figlie della contingenza è la chiave per la lunga vita. Usare esoterismi vari che si basano a sensazione o ad esperienza è deleterio.
2. Un buon progetto non è figlio della moda del momento: ogni tecnologia vive il suo momento di fulgore, ma ciò che rimane nel tempo sono le strutture consistenti. I progetti non sono laboratori in cui il professionista deve sperimentare ciò che sta imparando. Insomma, non è detto che si debba usare Kubernetes a tutti i costi per erogare il vostro WordPress.
3. Un buon progetto è ben documentato: la memoria fa brutti scherzi, verba volant, mettetela come volete, ma tutto quello che non si documenta verrà perso come lacrime nella pioggia. La documentazione non è un “di più” che si fa solo se si ha tempo, la documentazione è centrale per la sopravvivenza nel lungo periodo di un progetto.

Anche in questo caso la lista è una sintesi. E visto che di sintesi e semplicità stiamo parlando verrebbe da riassumere le soluzioni discusse sinora con una semplice, illuminante parola: empatia. Se nell’atto di creare qualcosa di nuovo si parte dal presupposto che qualcun altro dovrà metterci le mani, quanto descritto sinora si concretizzerà in maniera automatica. Ricordate quando parlavamo di TechDebts? Ecco, dire “faccio questa aggiunta poi vedrò di documentarla” non è utile a nessuno.

Perché poi, in fondo, l’altro che si troverà a guardare il proprio lavoro nella maggioranza dei casi sarai tu stesso, e il cielo ci scampi da quell’agghiacciante frase: “Ma sta schifezza l’ho scritta io?“.