<
AS
www.asinformatica.net
consulenza e sviluppo software
Simplicate and add lightness

Motto dei progettisti aeronautici e di auto da corsa, si potrebbe tradurre "cercate la semplicità e aggiungete leggerezza".

Il significato dell'affascinante verbo "to simplicate"; modellato su "to complicate", a cercarlo su Internet viene riportato come "ricerca di una semplicità apparente che nasconde la complessità" (Wikiquote) ovvero "ricerca della semplicità attraverso un percorso che non teme di esplorare la complessità" (Urban Dictionary). Personalmente preferisco la seconda sfumatura.

L'illusione di poter risolvere i problemi aggiungendo sempre nuovi elementi di complessità, ignorandone il peso sul contesto generale, trova un esempio clamoroso nella produzione normativa e regolamentare del nostro Paese; è un'evidenza sotto gli occhi di tutti, non è il caso di entrare qui nel tema, basta chiedere al vostro commercialista o tributarista.

Troppe volte anche nella produzione del software si cercano soluzioni attraverso la complessità: il nuovo miracoloso prodotto, linguaggio, libreria, architettura, pattern, da sovrapporre a quanto esiste. n questo modo si genera oscurità di disegno, moltiplicazione delle interdipendenze tra gli elementi del sistema, farraginosità negli interventi di modifica. E la soluzione miracolosa di oggi potrebbe rivelare col tempo limiti ed effetti collaterali che la rendono la trappola di domani.

Quel che non è immediato percepire è che la complessità è in sé un costo.

La realtà con cui lo sviluppo del software si deve confrontare, oggi e nel prevedibile futuro:

  • Il fabbisogno di software efficiente, affidabile, facile da usare sopravanza largamente la domanda che si esprime sul mercato, a causa di un evidente problema di risorse scarse (ovvero, nel linguaggio degli economisti, non disponibili in quantità sufficiente per ogni impiego, e tra le quali quindi occorre operare una scelta). E ciò perché la produzione di software è intrinsecamente costosa: è un'attività labour intensive, e per di più si tratta di lavoro qualificato, spesso condotto, per i progetti al di sopra di una certa dimensione, in teams che di necessità incorporano competenze diversificate e complementari, e quindi vanno gestiti e coordinati.
    Due sono allora le soluzioni: il committente è un'organizzazione che dispone delle risorse necessarie e ha esigenze che giustificano l'investimento. Ovvero il costo può essere ripartito tra una pluralità, più o meno vasta, di utenti. Ma inevitabilmente, quanto più si riducono i costi, tanto meglio si è in grado di rispondere al mercato. E, se posso permettermi di aggiungere, di migliorare in ultima analisi la qualità del lavoro e della vita di tutti, perché questo è il mestiere del softwarista
  • Le esigenze degli utenti del software sono in continua evoluzione. E in continua e vorticosa evoluzione sono anche gli strumenti di sviluppo, i linguaggi di programmazione, gli ambienti che ospitano il software e i dati su cui esso opera, le competenze richieste ad architetti, sviluppatori, sistemisti…
    Di conseguenza la produzione del software è un qualcosa di dinamico, che si estende nel tempo e a volte non si interrompe mai, tanto da potere essere paragonata più alla fornitura di un servizio che di un prodotto
  • Accade spesso che nel nostro settore si sia chiamati a intervenire per modificare e far evolvere un software monolitico, ma generato da una stratificazione di modifiche ed aggiunte successive, eseguite in genere sulla spinta di esigenze urgenti e quindi senza troppo preoccuparsi dell'impatto sul disegno complessivo, spesso con strumenti eterogenei e con soluzioni di fortuna.
    Può accadere anche che le competenze necessarie all'intervento sulle parti più "antiche" siano reperibili con difficoltà, o che sia praticamente impossibile modificare il software in modo da garantirne la sicurezza, a causa della vetustà della sua concezione.
    In situazioni del genere l'unica soluzione razionale è ripartire da zero, ma spesso è arduo farne comprendere la necessità e giustificarne il costo (la domanda da porre al cliente è "quanto costerebbe NON farlo?").

Che fare allora?

  • Per quanto possibile, togliere, non aggiungere. Una soluzione barocca, tortuosa e complicata potrebbe non avere alternative, ma non è mai una buona soluzione.
  • Modularizzare: costruire elementi di software tra di loro combinabili, comunicanti attraverso interfacce standard e indipendenti dalle tecnologie usate, e quindi modificabili e sostituibili indipendentemente l'uno dall'altro. In questo modo l'evoluzione del software potrà volare sulle ali dell'evoluzione delle tecnologie, non trovare ostacolo in essa.
  • Evitare la moltiplicazione di soluzioni e componenti prodotti da terzi e incorporati nella propria applicazione: il rischio è che cresca la quantità delle interdipendenze e dei single points of failure, e soprattuto che ci si trovi ad essere responsabili dei malfunzionamenti di qualcosa su cui non si ha controllo.
  • Evitare l'"inner platform effect", ovvero la tendenza a incapsulare, senza necessità, in codice sviluppato ad hoc funzionalità di per sé naturalmente disponibili nella piattaforma che si utilizza.
  • In un DB relazionale non è sempre utile usare tabelle di riferimento del tipo codice/descrizione.
  • Nuove e promettenti tecnologie, quali i microservices o la containerizzazione, introducono inevitabilmente aspetti di complessità che devono trovare una contropartita nella semplificazione di altri aspetti. Ciò generalmente è vero in casi in cui la realtà su cui si opera è di per sè molto complessa, altrimenti il rischio è di avere più svantaggi che vantaggi.
  • Il ricorso al cloud può risultare una semplificazione nel caso in cui risparmi investimenti in hardware e carico di lavoro ai sistemisti.
  • Eccetera...