Ponti, edifici e software

Fonte: rebaz007

Le metafore sono uno strumento eccezionale per comprendere rapidamente un concetto, creando una corrispondenza tra quello che conosciamo e quello che vogliamo conoscere. Nell’informatica si fa un grande uso di metafore, ma come talvolta accade, non sempre sono del tutto calzanti. Una di queste, in verità molto abusata, accosta lo sviluppo del software alla costruzione di ponti o edifici.
Probabilmente a primo acchito questa metafora rende l’idea a chi è proprio all’oscuro dellle problematiche di sviluppo del software, ma ad una attenta analisi essa risulta del tutto inadeguata e fuorviante.

Un edificio è qualcosa di fisico, tangibile, rigido per natura. Una volta costruito non è facile apportarvi modifiche strutturali, spostare un muro, costruirvi un altro piano sopra o un parcheggio sotto le fondamenta. Una volta definito il progetto, certe modifiche in corso d’opera risultano impossibili o troppo costose. Dopo la realizzazione non è possibile intervenire sui materiali usati, sulle tecniche di costruzione per migliorarlo o per adeguarlo a nuove esigenze.

Un software invece è un sistema flessibile, malleabile, adattabile, in evoluzione continua per esigenze dell’utente e/o dello sviluppatore. Proprio questo aspetto soft è allo stesso tempo il pregio e il difetto (in senso lato) del software.

Qualcuno ha suggerito metafore alternative per catturare questa natura evolutiva del software associandolo all’urbanistica o al giardinaggio o ad altre discipline. In ogni caso, ogni metafora lascia sempre, per sua natura, qualcosa di non definito.

Ma riflettiamo un attimo. Se vado da un ingegnere perchè voglio che mi progetti una casa, io sto chiedendo di fare qualcosa che lui sa fare bene. Lui sa come progettare edifici. Conosce le leggi della fisica e la normativa edilizia.

Se vado da uno sviluppatore e gli chiedo di realizzare un software per la gestione della contabilità di un ente pubblico, lo sviluppatore può anche essere preparatissimo da un punto di vista tecnico, ma deve in ogni caso avvicinarsi alla conoscenza della contabilità degli enti pubblici. In altre parole, alle variabili tipiche della propria attività si aggiungono le variabili legate alla conoscenza del dominio del problema.

Se volessimo mantenere in qualche modo l’analogia con l’edilizia, sarebbe come se un ingegnere volesse costruire un edificio senza conoscere a fondo le leggi della fisica. Sarebbe costretto a sperimentare soluzioni senza poter dare un adeguata garanzia di successo.

Lo sviluppo del software è più simile alla sperimentazione, alla ricerca di una soluzione in mancanza di una conoscenza completa del dominio del problema. Mentre l’ingegnere edile ha sotto controllo tutte le variabili del problema, l’ingegnere del software deve colmare la lacuna della conoscenza approfondita del problema che deve gestire.

Alla mancanza di conoscenza si aggiunge il problema della comunicazione con l’utente, non sempre chiara e trasparente, e la mutevolezza delle specifiche iniziali, talvolta nemmeno chiare all’utente stesso.

Il tutto si traduce in un alto grado di incertezza, un po’ come nella ricerca scientifica. Incertezza da gestire accuratamente e tempestivamente mettendo al centro dell’attività di sviluppo la comunicazione.

D’altronde tutto nel software ruota intorno alla comunicazione, a partire dal linguaggio di programmazione.