Complessità e sforzo

Partiamo da un diagramma semplice. Sull’asse orizzontale (X) è rappresentata la complessità del problema informatico da risolvere. Sull’asse verticale (Y) è rappresentato il costo, cioè lo sforzo necessario per costruire una soluzione software.

La comunità scientifica concorda su un punto: all’aumentare della complessità del problema cresce anche lo sforzo richiesto per risolverlo. Questa crescita non è lineare: in molti casi è più che proporzionale e in alcune situazioni può diventare persino esponenziale.

Una lettura molto semplificata dell’ingegneria del software è proprio questa: trovare modi per affrontare problemi sempre più complessi mantenendo lo sforzo entro limiti ragionevoli (nel percorrere la linea verde anziché la linea nera, vedi prossimo diagramma). Nel tempo la disciplina ha sviluppato linguaggi, architetture, metodi e strumenti che permettono di spostare il rapporto tra complessità e costo verso soluzioni più gestibili.

Tecnologie diverse, curve diverse: il punto Q

Lo stesso tipo di diagramma può essere utilizzato per descrivere l’effetto dell’adozione di tecniche o tecnologie differenti. Per rendere il concetto più leggibile, usiamo un esempio volutamente classico: immaginiamo che la curva nera rappresenti l’andamento tipico del rapporto complessità-costo con un linguaggio di programmazione strutturato (ma non a oggetti), mentre la curva verde rappresenti lo stesso rapporto nel caso di impiego di un linguaggio a oggetti. Il ragionamento vale identicamente per le scelte tecnologiche di oggi: monolite e microservizi, orchestrazione sincrona ed event-driven, infrastruttura gestita manualmente e infrastructure as code.

La curva verde intercetta l’asse Y in un punto più alto. Questo significa che adottare soluzioni più strutturate richiede uno sforzo iniziale maggiore. Programmare a oggetti è più impegnativo rispetto a programmare con un linguaggio strutturato. Scrivere un’applicazione a microservizi è più complesso rispetto a scrivere un’applicazione monolitica.

Le due curve si incrociano in un punto. Chiamiamo Q quel punto sull’asse X. Prima di Q la soluzione meno strutturata costa meno. Dopo Q la soluzione più strutturata diventa progressivamente più efficiente. Questo significa che certe tecniche hanno senso solo per problemi di dimensione uguale o superiore a Q.

Questo fatto, apparentemente banale, spiega molte discussioni ricorrenti nel settore. Persone anche molto competenti, che siano però abituate a problemi di dimensione inferiore a Q, percepiscono come inutili sovrastrutture un insieme di tecniche e metodologie che hanno senso solo per problemi più grandi. Non è un problema di competenza: stanno semplicemente guardando la stessa curva da un punto diverso dell’asse X. Si potrebbe dire che ogni tecnologia corrisponda a una certa curva, e che per ciascuna si debba valutare se applicarla o meno dato il problema specifico.

L’effetto dell’esperienza

Quando una tecnica viene utilizzata più volte, il costo iniziale tende a diminuire. Se un team ha già imparato a programmare a oggetti per un progetto, il costo di quell’apprendimento non va ripagato nei progetti successivi. Graficamente, questo equivale a traslare la curva verde verso il basso. La curva verde chiaro nel diagramma seguente rappresenta la stessa tecnologia della curva verde scuro, ma applicata da chi ne ha già acquisito la padronanza.

Per questo motivo professionisti con maggiore esperienza tendono a utilizzare tecnologie strutturate anche su problemi relativamente piccoli: per loro il punto Q si è spostato a sinistra. Chi invece non ha ancora familiarità con quegli strumenti percepisce il costo iniziale in modo più marcato e tende a preferire soluzioni più semplici.

La differenza non riguarda solo la tecnologia. Riguarda la competenza di chi la utilizza. La possibilità di ottenere risultati in modo efficiente dipende sia dalla tecnologia scelta sia da chi la deve mettere a terra e mantenerla operativa. 

La curva rossa: la tecnologia usata male

C’è un ultimo aspetto del diagramma che merita attenzione. Quando una tecnologia potente viene adottata senza la competenza necessaria per utilizzarla correttamente, il risultato non è neutro. È peggiore di quello che si sarebbe ottenuto con strumenti più semplici. Nel diagramma, questo scenario corrisponde alla curva rossa.

La tecnologia da sola non è la soluzione. La soluzione è la tecnologia collegata a come la si usa. Java è un linguaggio a oggetti ottimo, ma utilizzare Java non è garanzia di per sé di scrivere applicazioni di qualità. Si può scrivere un programma in Java senza errori, che il compilatore compila e che può essere messo in esecuzione, e che nonostante ciò è pessimo dal punto di vista della manutenibilità e non solo di quella. In un altro ambito si potrebbe dire che un buon vocabolario e un buon libro di grammatica non garantiscono da soli di diventare buoni scrittori.

Il ruolo dell’ingegneria del software

Questo tema è molto presente in informatica e tocca tre dinamiche che si influenzano a vicenda e che vale la pena distinguere.

La prima è la commoditization. Le funzionalità che un software offre oggi domani saranno considerate il minimo indispensabile dai suoi utenti. Per rimanere al passo, i software offrono sempre più funzionalità, il che significa che gli sviluppatori si troveranno ad affrontare applicativi sempre più grandi. Il fatto che certe funzionalità siano considerate ovvie dagli utenti non vuol dire che si facciano da sole. Detto altrimenti: al trascorrere del tempo i problemi da affrontare sono sempre più grandi, e chi sviluppa è praticamente obbligato a adottare nuove tecniche e tecnologie, a volte contro voglia o senza avere particolari competenze.

La seconda è l’hype. In ogni periodo ci sono tecnologie particolarmente di moda, e i commerciali puntano molto su di esse per promuovere i prodotti. La logica è quella del B2B2C: “compra il mio sistema perché usa Mongo” (e non il vecchio e decrepito Oracle). Ogni momento storico ha i suoi tormentoni: multimodale, blockchain, big data, IoT, enterprise service bus, metaverso e, di recente, AI. Nessuna di queste tecnologie è necessariamente sbagliata. Anzi, con tutta probabilità hanno cose utili da offrire. Il problema è che l’hype alto arriva solitamente prima della maturità nelle tecniche e nelle metodologie per usarle bene. È facile usarle a sproposito, e spesso si è spinti a adottarle non per scelta tecnica ma per pressione commerciale.

La terza è la maturità. Ci possono essere problemi anche con tecnologie ormai mature e uscite dal ciclo di hype, ma la dinamica è diversa. Una tecnologia matura diventa facile da usare: oggi scrivere un web service REST è un’operazione accessibile a molti. La questione è che una tecnologia facile da usare a volte viene usata troppo o a sproposito. La tecnologia rende possibile scrivere un web service. Non spiega quando vale la pena scriverlo. In questo caso il rischio non è l’incompetenza ma l’overengineering: aggiungere complessità dove non serve.

Il problema nasce quando queste tre dinamiche si sovrappongono e si perde consapevolezza dello scopo ultimo di una tecnologia e della teoria necessaria per applicarla in modo opportuno. Il rischio è quello di seguire le mode del momento, scegliendo un linguaggio o un database senza un reale criterio o una comprensione profonda. Quando questo accade, si percorre la curva rossa del diagramma. Chi non sa programmare a oggetti e prova a farlo comunque può produrre un risultato peggiore rispetto a quello che avrebbe ottenuto con un linguaggio meno complesso.

Ingegneria del software significa utilizzare la tecnologia giusta nel momento giusto nel modo appropriato, perché solo così è possibile affrontare in modo positivo problemi complessi. È per questo motivo che sul nostro sito non troverai una lunga fila di sigle e acronimi corrispondenti alla moda del momento. Siamo sicuri che molti li conosciamo. Siamo ancora più sicuri che quelli davvero necessari li adopereremo.