software engineering

Un backlog è una lista di cose da fare. Nel backlog dello sviluppo software, le cose da fare appartengono a diverse categorie: nuove funzionalità per gli utenti, adeguamenti tecnici, correzione di errori. Anche la riduzione del debito tecnico rientra tra le cose che è opportuno fare.

Un'utile visualizzazione delle diverse tipologie di attività è stata proposta da Claude Aubry.

Ecco una versione italiana del suo quadrante del backlog:

Quando il software è fatto bene, gli utenti lo usano senza problemi. Chi dà assistenza non è subissato dai reclami. Per chi lo fa evolvere è facile aggiornarlo, modificando le funzioni esistenti quando è il caso, o introducendone di nuove.

Non tutti, purtroppo, viviamo in questo mondo ideale. Non sempre, almeno. Perché il software può essere anche fatto male, e (se lavoriamo nel settore dello sviluppo software) può darsi che l'abbiamo fatto male noi.

Perché, a volte, il software è fatto male? In alcuni casi, per l'incompetenza di chi lo sviluppa, problema in genere superabile con un'adeguata formazione professionale. In altri casi, però, il motivo non è la mancanza di competenza. Anche sviluppatori molto capaci producono a volte software non ottimale. Per fare più in fretta, per spendere meno tempo, perché non c'è più tempo. Per rilasciare prima, in tempo, la nuova versione del software.

Ogni volta che produciamo un software con dei problemi, che lo modifichiamo in un modo non ottimale, ad esempio facendo “copia e incolla” di porzioni di codice invece di riprogettare adeguatamente il programma, diminuiamo il livello di qualità del prodotto. Rendiamo più difficili, lunghe e costose le modifiche successive, che verranno anch'esse, probabilmente, fatte male. Così il software degrada ad ogni successiva modifica, e può accadere che anche prodotti inizialmente validi peggiorino ad ogni nuovo rilascio.

Questo è il debito tecnico. “Debito tecnico” è una metafora ideata da Ward Cunningham per far capire, sia agli sviluppatori che ai non addetti ai lavori, il costo economico che ha un intervento non ottimale sul software. Ogni volta che contraiamo un debito, ad esempio un mutuo (o il debito pubblico di una nazione), dobbiamo ripagarlo con gli interessi. Nel caso del software, ogni volta che effettuiamo un intervento inadeguato, scegliendo la strada più veloce anziché la migliore, abbassiamo la qualità e rendiamo più difficili e costosi gli interventi futuri.

Questo non significa che fare in fretta non sia necessario. A volte dobbiamo per forza scegliere la strada veloce anziché la migliore, perché non abbiamo alternative. Ma poi bisogna mettere le cose a posto, se si vuole evitare il peggio.

L'Object Management Group (OMG) ha pubblicato un documento sull'automazione del conteggio dei Punti Funzione (Function Point), la metrica più diffusa a livello internazionale per misurare le dimensioni delle applicazioni software (cioè per dare risposta alla domanda: quanto è "grande" un software?).

Il conteggio dei Function Point è utile sotto diversi punti di vista, per governare sistemi informativi complessi e misurare livelli di qualità e di produttività; viene spesso usato anche per stimare, negoziare e tenere sotto controllo i rapporti di outsourcing tra clienti e fornitori nell'ambito dello sviluppo software. Il conteggio viene svolto tradizionalmente in modo "manuale", ed è un'attività onerosa che richiede una elevata competenza specialistica.

Il documento OMG sull'automazione del conteggio dei Function Point, in versione beta (lo stadio precedente all'emanazione come standard ufficiale), è disponibile con il titolo "Automated Function Points" sul sito del Consortium for IT Software Quality (CISQ), nella sezione riservata ai membri: l'iscrizione è gratuita e consente lo scarico del documento.

Una conversazione tra Capers Jones, massimo esperto di "metriche" sulla qualità e sui rischi del software, e Ward Cunningham, ideatore del concetto di debito tecnico (oltre che dei wiki, dello sviluppo agile, e di varie altre cose).

La qualità della registrazione audio è scadente, ma la trascrizione merita una lettura.

Pubblicata la descrizione del Kernel di Semat, l'iniziativa guidata da Ivar Jacobson per la rifondazione dell'ingegneria del software.

Per chi desidera una descrizione approfondita c'è un libro; per chi vuole informazioni preliminari è disponibile un articolo su ACM Queue.

Technical Debt: From Metaphor to Theory and Practice, di Philippe Krutchen, Robert Nord e Ipek Ozkaya, è l'articolo introduttivo ad una serie di contributi sul debito tecnico apparsi in IEEE Software, November/December 2012.

Software Engineering Radio. The Podcast for Professional Software Developers.

Interviste mensili sui temi dello sviluppo software, scaricabili come podcast.

Creato e gestito a partire dal 2006 da Markus Voelter, dall'inizio del 2012 è condotto in associazione con la rivista bimestrale IEEE Software.

Gli episodi sono spesso interessanti, come ad esempio l'intervista a Martin Fowler e a Pramod Sadalage su "Agile Database Development".

Nei paesi più vitali dal punto di vista economico, come Stati Uniti, nord Europa, Cina, India, il ruolo del programmatore software è ben conosciuto, e considerato in modo molto positivo.

Lo sviluppo software è trattato frequentemente dai media non specializzati (giornali e riviste per non addetti ai lavori, televisioni). I programmatori compaiono nelle pubblicità e in fumetti diffusi, come Dilbert. Soprattutto, partiti politici e governi hanno ben chiara l'importanza dello sviluppo software e provano ad incentivarlo il più possibile.

Un esempio: in Estonia è stata appena approvata una legge per insegnare la programmazione nelle scuole, a partire dalle elementari, in quanto la programmazione software è ritenuta un fattore strategico per il paese e in Estonia, dove tra l'altro si sviluppa Skype, mancano programmatori.

In Italia, invece, il ruolo di programmatore software è da sempre poco noto. Se ne parla poco, o per nulla. E laddove è conosciuto, come all'interno dei settori IT delle organizzazioni (grandi e medio-grandi), è considerato come un ruolo di secondo piano.

Almeno dagli anni settanta del '900, esistono centinaia di migliaia di persone che operano nel campo del software in Italia. Ma mi occupo di informatica da oltre 30 anni e mi è capitato molto raramente di leggere un articolo sullo sviluppo software in una rivista non specializzata. Sarò stato distratto, forse. Ma sicuramente si è parlato molto di più dei tassisti.

Forse è anche per questo motivo che l'immagine sociale del programmatore software in Italia è così scarsa. In molte organizzazioni italiane il ruolo del programmatore è probabilmente uno di quelli meno considerati. Un ruolo di basso livello, operativo, con basso status sociale. Uno dei primi ruoli da eliminare, da esternalizzare, perché non porta valore aggiunto all'azienda.

Ma forse, invece, a ben guardare, lo sviluppo software porta valore aggiunto. Forse, la programmazione software non è affatto un'attività operativa, ripetitiva, di basso livello intellettuale.

Lo dimostrano i paesi più dinamici e vitali dal punto di vista economico, che hanno bisogno di programmatori e cercano in ogni modo di attrarli dall'estero. E anche molte aziende, come la General Motors, che dopo aver attraversato ed essere uscita da una crisi profonda ha capito che si era spinta troppo in là, con l'outsourcing dello sviluppo software, e sta ora assumendo migliaia di programmatori.

Deve essere installato e funzionare. Se lo è,
deve avere sufficienti prestazioni, ed essere sicuro. Se lo è,
deve essere usabile. Se lo è,
deve essere utile. Se lo è,
può avere successo.

Rappresentata come una piramide, questa scala di livelli di qualità del software è analoga alla piramide di Maslow sul soddisfacimento dei bisogni degli esseri umani.

Per Maslow, innanzitutto vanno soddisfatti i bisogni primari (cibo, temperatura ecc.). Soddisfatti questi, vanno soddisfatti i bisogni di sicurezza personale. Poi i bisogni legati alle relazioni e all'affettività. Poi i bisogni legati al riconoscimento e alla stima. Infine quelli legati alla realizzazione del proprio potenziale.

Se un livello precedente non viene soddisfatto, vengono compromessi i livelli successivi (ad esempio, se non si ha cibo sufficiente, l'attenzione alla sicurezza personale può diminuire).

L'analogia tra la scala dei bisogni di Maslow e i livelli di qualità del software è descritta in modo brillante da Gojko Adzic.

Contraiamo un debito tecnico ogni volta che interveniamo su un sistema in modo non ottimale. Prima o poi, lo si paga. Ma chi lo paga?

Un articolo di Eric Allman, su Communications of the ACM, May 2012, "Managing Technical Debt.

"... the person who takes on technical debt is not necessarily the one who has to pay it off—in fact, most of the time the one who takes on the debt can shuffle the costs on to other people, which encourages taking on debt. Far too many developers do not maintain their own code. Many companies have a policy that software moves from a development mode that is staffed by their best programmers to a maintenance mode staffed by secondtier engineers (who are paid less but often have far more difficult jobs than the premier team). Sometimes it isn't even anyone in your organization who is paying the interest: it's the users who have to pay. Developers are rewarded more on implementation speed than long-term maintainability and may have moved on to a different project or company before the real cost is paid. This gives the initial developer little incentive to do the job right the first time."