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:

  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.

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?“.

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.

3 risposte a “Saturday’s Talks: la complessità del mondo software ci seppellirà, se non impariamo l’empatia”

  1. Avatar eueuropean
    eueuropean

    Complimenti, ottimo articolo.

  2. Avatar amedeo lanza
    amedeo lanza

    Sintetizzare in tre punti le cose essenziali per un buon progetto penso che sia impossibile. In tanti anni di esperienza nello sviluppo ho visto come molti aspetti che un buon sviluppatore dà per scontati, sono completamente ignorati. Uno dei punti fondamentali sarebbe avere delle specifiche chiare, non doverle cambiare al volo nel corso dello sviluppo. Sto lavorando su un import, partito con un tracciato indicato dal cliente /non senza una certa approssimazione) per arrivare a dover indicare io al cliente il tracciato corretto da generare dall’export (su altro sistema). Ho dovuto intervenire più volte per modificarlo a causa delle specifiche estremamente carenti che non prevedevano aspetti essenziali dell’importazione. Ora devo stravolgere il tutto per ottimizzare, visto che provvedono ad esportare sempre tutto il magazzino invece di produrre solo un differenziale.
    Ultima chicca: dopo che ho impostato una serie di ambienti per il ciclo di vita (wrk, dev, pro), essere riuscito a far utilizzare Git dopo almeno un anno di insistenze, il responsabile del progetto (io lavoro come consulente) ha deciso che la macchina di sviluppo (dev) dovesse diventare quella di produzione e per farlo ha semplicemente spento quella di produzione ed aggiunto l’alias alla configurazione del webserver a quella nato per lo sviluppo.

    Ora c’è un ambiente di produzione in …/dev.dominio… con utenti del tipo progetto_dev, database progetto_dev e bisogna ricordarsi che quel progetto è gestito in maniera ‘personalizzata’.
    Il tutto condito dal dover gestire i tool per la distibuzione e manutenzione per ambienti diversi (plesk, ispconfig, cyberpanel e forse uno o due altri) con tutte le pippe mentali necessarie per sapere dove siano le cose (percorso webroot, esequibile php ecc.)

  3. Avatar Raoul Scarazzini

    Per quanto più che legittimi i punti che esponi li trovo fin troppo tecnici. L’aspetto su cui mi interessa focalizzare l’attenzione è più “filosofico”, e riguarda molto di più l’approccio che si dovrebbe adottare per avere progetti di qualità.

    Vien da sé che se i presupposti del progetto ad un certo punto cambiano radicalmente, e non per volontà di chi sta cercando di fare ordine, c’è poco da fare: non ne si esce. E di nuovo quindi si torna al tema dell’empatia: finché non ci si metterà nei panni di chi poi deve correre ai ripari si finirà sempre dire “fai così e basta”, che è la cosa peggiore.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *