Lo sviluppo software è un lavoro difficile da spiegare a chi non lo pratica in prima persona. D’altra parte, è un lavoro diffuso (gli sviluppatori sono molti) e con effetti rilevanti su chi fa altri mestieri (tutti sono in qualche modo toccati dal software). Quindi vale la pena cercare di spiegare in cosa consiste, anche per sfatare due luoghi comuni molto diffusi:

1. Che lo sviluppo software sia analogo, o comunque riconducibile alla produzione industriale (o all’edilizia).
2. Che lo sviluppo software sia un’attività particolarmente adatta alle persone meno socievoli, restie a lavorare insieme ad altri.

Si tratta di luoghi comuni paradossali, per chi pratica lo sviluppo software come lavoro.
Ma pervasivi, e purtroppo diffusi anche tra i manager degli sviluppatori, a volte con effetti disastrosi in termini di scelte organizzative, nonché di selezione e formazione del personale.

Un lavoro intellettuale complesso

Lo sviluppo software è un lavoro intellettuale complesso, in cui gli aspetti sociali (gestione delle relazioni, e delle comunicazioni) sono preponderanti rispetto a quelli tecnologici.

La natura dello sviluppo software consiste nell’acquisizione di conoscenza su un problema concreto (l’ambito applicativo, che può essere relativo ai settori più diversi), e nella trasposizione di questa conoscenza, tramite opportuni processi di astrazione, in un sistema informatico [1].

La complessità dello sviluppo software deriva da tre cause principali:

• Il problema da risolvere può essere complesso in sè, per il numero di concetti coinvolti, per la complessità delle loro caratteristiche e delle loro interrelazioni.
• La definizione del problema e delle soluzioni avviene socialmente, tramite il dialogo tra chi vuole il sistema (committente) e chi lo deve realizzare (sviluppatore). Nella maggioranza dei casi, né il problema né le soluzioni sono perfettamente definiti all’inizio dello sviluppo. Vengono determinati progressivamente nel corso del progetto.
• La soluzione al problema è vincolata dalle caratteristiche delle tecnologie disponibili.

Ogni progetto di sviluppo software ha degli obiettivi, che devono essere raggiunti per soddisfare il committente e gli utilizzatori (anche quando, come normalmente accade, i requisiti si chiariscono in corso d’opera). Ha un costo, che deve essere il minore possibile. Ha dei tempi, anch’essi soggetti a vincoli. Si svolge in un concreto contesto sociale, con concreti condizionamenti e vincoli culturali.

Né industria, né edilizia

Una certa scuola di pensiero tende, equivocando, ad equiparare lo sviluppo software alla produzione di beni industriali.

Secondo questo punto di vista, se lo sviluppo software non avviene in modo “industriale” è
perché si tratta di una disciplina ancora giovane, e bisogna compiere ogni sforzo per allinearla al modo di operare dei settori più maturi.
Di qui, l’idea di costruire “software factories”, fabbriche del software. Di qui, anche, la tendenza a riproporre nello sviluppo software modelli organizzativi basati sulla specializzazione dei ruoli e sulla sequenzialità della catena di montaggio (con un ritardo di un secolo rispetto a quanto accade nelle vere aziende industriali…) [2].

In realtà, lo sviluppo software non ha alcuna somiglianza con il processo di produzione industriale. La “produzione”, cioè la creazione di migliaia o milioni di copie identiche a partire da un modello, in un progetto software ha un costo percentuale tendente allo zero. Lo sviluppo software ha, invece, notevoli affinità con la progettazione di nuovi prodotti industriali. Dalla definizione dei primi modelli alla scrittura del codice in un linguaggio di programmazione, tutto lo sviluppo software è, a livelli di dettaglio diversi, un’attività di design.

L’analogia dello sviluppo software con l’edilizia civile è più recente, e certamente meno impropria, rispetto a quella con la produzione industriale, perché mette in risalto gli aspetti di design, e in qualche modo l’unicità del prodotto dei progetti di sviluppo.

Esiste però una differenza di fondo, tra l’edilizia e lo sviluppo software. Quando si costruisce una casa, la distinzione tra la fase di progettazione e la fase di realizzazione dei lavori è molto marcata. Una volta realizzate, le decisioni prese durante la progettazione edilizia sono modificabili solo con molta fatica, perché i materiali hanno il peso e l’inerzia derivanti dalla loro fisicità.

Nel software è diverso. Tutto il progetto è design, non solo la fase iniziale. Ed è, soprattutto, un design di astrazioni. Il “materiale” sono astrazioni, che si potranno modificare in qualsiasi momento del progetto, e anche in evoluzioni future del software prodotto. Anche le modifiche al software costano fatica, ci mancherebbe. Ma costano molta meno fatica di quelle necessarie per modificare scelte architetturali nel campo dell’edilizia, perché le astrazioni sono comunque più malleabili del cemento e dei mattoni.

Un lavoro che si svolge in un contesto sociale concreto

L’immagine più nota dello sviluppatore software è quella del “geek”, un giovane maschio introverso e brufoloso che comunica il meno possibile, e quando lo fa utilizza un incomprensibile gergo per iniziati.

In realtà, lo sviluppo software è un lavoro in cui sono essenziali gli aspetti di comunicazione e di relazione con gli altri. Aspetti illustrati in modo spesso realistico nel cartoon Dilbert [3], e trattati in modo più sistematico nel classico Peopleware [4] e nei lavori di Alistair Cockburn [5], che evidenzia l’aspetto cooperativo delle attività di sviluppo:

“Lo sviluppo software è una serie di giochi cooperativi di invenzione e comunicazione, con risorse limitate e finalizzati ad un obiettivo. L’obiettivo primario di ogni gioco è la produzione e la consegna di un sistema software; ciò che rimane alla fine del gioco è un insieme di note, utilizzabili per assistere i giocatori del gioco successivo. Le persone utilizzano note e appunti per ricordare, trarre indicazioni e comunicare tra loro, allo scopo di passare alla mossa successiva del gioco. Il gioco successivo è la variazione del sistema, oppure la creazione di un sistema contiguo. Ogni gioco ha quindi come obiettivo secondario quello
di conseguire una posizione vantaggiosa per il gioco successivo. Poiché ogni gioco si svolge a risorse limitate, l’obiettivo primario e quello secondario competono tra loro per le risorse disponibili.”

Le interazioni sociali importanti e determinanti per l’andamento e per l’esito del progetto sono più di una:

1. quelle tra chi vuole lo sviluppo del sistema (il committente) e chi lo sviluppa (il fornitore-sviluppatore)
2. quelle tra il committente e l’insieme delle parti interessate all’esito del progetto (gli stakeholder), compresi i futuri utilizzatori
3. quelle interne al gruppo di sviluppo (che in parecchi casi non è un gruppo unitario, ma una serie di gruppi distinti che devono cooperare tra loro)

La prima relazione, tra il committente e il fornitore, determina la gestione degli aspetti contrattuali ed economici del progetto, il processo di sviluppo, il controllo sull’avanzamento dei lavori, le modalità di gestione dei rischi, le modalità di comunicazione e di gestione complessiva dei requisiti.

La seconda, tra il committente e gli altri stakeholder, influenza la determinazione specifica dei requisiti e delle priorità, la gestione del conflitto tra esigenze concomitanti e concorrenti, l’accettazione futura del sistema da parte di chi dovrà utilizzarlo.

La terza, interna al gruppo di sviluppo, influenza in modo determinante la produttività e la qualità del processo e del prodotto finale.

---

Riferimenti:

[1] – Philip Armour – The Laws of Software Process. A New Model for the Production and Management of Software, Auerbach 2004

[2] – Mary e Tom Poppendieck – Lean Software Development, Addison Wesley 2003

[3] – Scott Adams – Dilbert

[4] – Tom De Marco e Timothy Lister – Peopleware: Productive Projects and Teams , 2nd Edition Dorset House 1999 (1a edizione 1987)

[5] – Alistair Cockburn – Agile  Software Development , Addison-Wesley 2001