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.
Una cosa che favorisce la complessità, comunque, è che agli ingegneri piace. Ammettetelo: per quanto ci si lamenti della complessità altrui, ci piace la nostra. Adoriamo stare a pensare a nuovi diagrammi architetturali che risiedono nella nostra testa. È solo quando questi diagrammi lasciano la nostra testa e prendono forma nel mondo reale superando in grandezza la testa di chiunque altro che iniziano i problemi.
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:
- 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.
- 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à.
- 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:
- 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.
- 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.
- 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?“.
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
