[CleanCode] Il test di Joel: 12 domande per migliorare il tuo codice

Hai mai sentito parlare del SEMA? Si tratta di un sistema, piuttosto esoterico a dire il vero, per misurare l’abilità di un team di sviluppo di software. No, aspetta! Non cercare di informarti sul SEMA! Ti ci vorrebbero almeno sei anni solo per cominciare a capire di che si tratta. Così ho preferito inventarmi il mio personalissimo, poco scientifico e inadeguato test per la valutazione della qualità di un team di sviluppo software. La cosa interessante di questo test è che richiede al massimo tre minuti, così con tutto il tempo che puoi risparmiare puoi iscriverti a un corso di medicina.

Il test di Joel

  1. Utilizzi un prodotto per il controllo del versioning dei file?
  2. Riesci a compilare un intero programma con un solo comando?
  3. Crei almeno una build al giorno?
  4. Hai un sistema di gestione dei bug?
  5. Sei solito risolvere i bug prima di scrivere del nuovo codice?
  6. Hai un programma di sviluppo aggiornato?
  7. Hai un documento di specifiche?
  8. I tuoi programmatori lavorano in un ambiente tranquillo?
  9. Ti servi dei migliori prodotti presenti sul mercato?
  10. Hai dei tester nel tuo team?
  11. Durante il colloquio, fai scrivere del codice a chi si presenta per far parte del tuo team?
  12. Fai eseguire dei test di usabilità a sorpresa?

La cosa interessante del Test di Joel, è che ti permette facilmente di dare una risposta a ogni domanda, sia essa sì o no. Non hai bisogno di immaginarti il numero di righe di codice che sei in grado di produrre al giorno, o il numero medio di bug che riesci a chiudere. Basta che assegni al tuo team un punto per ogni “sì”. Purtroppo, la cosa brutta di questo test è che non dovresti assolutamente utilizzarlo, in modo da evitare possibili svenimenti.

Un punteggio complessivo di 12 rappresenta la perfezione, 11 è invece tollerabile, ma realizza 10 o meno e stai certo che andrai incontro a problemi piuttosto seri.
La verità, purtroppo, è che la maggior parte dei team di progetto realizza punteggi compresi tra 2 e 3 e ha bisogno veramente di un grande supporto, dato che compagnie come Microsoft viaggiano a ritmi da 12 a botta.

È ovvio che quelli elencati non sono gli unici fattori che concorrono al successo o al fallimento di un team: per esempio, qualora avessi a disposizione un team eccezionale per la realizzazione di un software che comunque non interessa a nessuno, bé la gente non lo acquisterebbe lo stesso.
Ed è anche possibile che un team di imbranati, incapace a rispondere affermativamente a una sola delle mie domande, riesca comunque a produrre un software fantastico, capace di cambiare il mondo. In ogni modo, non considerando questi fattori esterni, è un dato di fatto che se ottieni un 12 secco, potrai contare su un team disciplinato e capace di consegnare il prodotto in qualunque momento.

Continua la lettura

La legge di Metcalfe e i nostri “amici” sui social network

Leggendo un articolo pubblicato sul celebre blog di Joel Spolsky, mi sono imbattuto nella legge di Metcalfe, probabilmente valida (o possiamo dire “applicabile”) nel campo delle tecnologie delle reti informatiche, ma che potrebbe essere “obiettabile” nel contesto delle reti sociali, viste come interconnessioni di individui che si servono delle reti informatiche suddette come mezzo di comunicazione.

Ecco cosa dice la legge (definizione tratta dal Wikipedia – La legge di Metcalfe):

Definita da Robert Metcalfe, l’ideatore delle reti Ethernet, la Legge di Metcalfe afferma che “L’utilità e il valore di una rete sono pari ad n^2 – n dove n è il numero degli utenti”, trasformata in simboli:

N(N−1), oppure N²−N.

Tale legge spiega molti degli effetti delle tecnologie della comunicazioni e delle reti come Internet e il World Wide Web.

La legge di Metcalfe mette in rilievo il denominatore comune di tutte le tecnologie di comunicazione: il valore di una rete cresce esponenzialmente all’aumentare del numero dei suoi utenti.

Se nessuno utilizzasse una tecnologia, qualsiasi essa sia (dal un telefonino ad un social network come Facebook/Twitter), il suo valore intrinseco sarebbe nullo. Al contrario, più utenti la utilizzano, più il valore della tecnologia risalirebbe esponenzialmente. Ciò porta a rendere applicabile la legge di Metcalfe anche al contesto del marketing, il cui concetto è ben esplicato nell’articolo pubblicato su WebCopywriter.it (La legge di Metcalfe applicata al marketing):

Ora, se una tecnologia ha bisogno di tanti utenti per accrescere il proprio valore in maniera esponenziale allo stesso modo il marketing ha bisogno di una massa di utenti per rendere di successo le proprie campagne? Solo quando un’idea di marketing diventa così popolare da essere condivisa dalla stragrande della maggioranza del target di riferimento può diventare stratificazione culturale ed il brand può trasformarsi in lovemark? Prendiamo Apple: i suoi utenti sono talmente soddisfatti dei prodotti ed è talmente alta la reputazione di cui gode quella tecnologia ai loro occhi per cui si può parlare di una vera e propria sedimenzione culturale: il senso di quella tecnologia si confonde con l’insieme delle visioni dei suoi utenti, che diventano a tutti gli effetti i detentori del valore di quella tecnologia.

Si sta rivalutando, tuttavia, la legge poichè è alquanto ottimista: sempre su Wikipedia si legge che: “in un articolo pubblicato nel marzo 2005, due ricercatori dell’università del Minnesota, Andrew Odlyzko e Benjamin Tilly, sostengono che la legge di Metcalfe è eccessivamente ottimista. Secondo i ricercatori il difetto principale della legge di Metcalfe è che essa considera tutti i componenti di una rete di uguale importanza, quando in effetti non lo sono. I ricercatori propongono una nuova legge che regola la crescita del valore di una rete in modo logaritmico, che tiene conto di questo fattore importante. Il valore della rete e la sua crescita avviene dunque in modo meno spettacolare”.

L’obiezione che si potrebbe fare riguarda l’applicazione della legge nell’ambito delle reti sociali (da cui siamo partiti): cosa accade se in un social network il gruppo di utenti interconnessi diventa troppo grande?
Un numero troppo grande di partecipanti uccide di per sè la conversazione. L’ideale sarebbe avere un numero elevato di scambi bidirezionali. La legge di Melcalfe (dove il numero di connessioni cresce in ragione del quadrato del numero di nodi) applicata a questo contesto, evidenzia quanto l’aumentare dei partecipanti possa essere un ostacolo. Poiché il numero di potenziali scambi bidirezionali in un gruppo cresce più velocemente del gruppo stesso, l’unità viene a mancare rapidamente man mano che il sistema di ingrandisce. Bisogna fare in modo che gli utenti si attengano allo schema di “pochi ma buoni”, al fine di mantenere la coesione del gruppo.

Attenzione, parliamo di comunicazione/conversazione nell’ottica sociale del termine. E’ ovvio che se il numero di utenti a cui posso veicolare un messaggio (magari pubblicitario) è grande, migliore ne sarà la sua diffusione, ma qui ci ricolleghiamo al contesto del marketing su esposto.

In poche parole, non ha senso avere troppi “amici” su Facebook o Twitter (solo per far numero). Su tutti gli “amici” che abbiamo, ci metteremmo in contatto con meno del 10% di questi.

“Il valore di un social network è definito non solo da chi c’è dentro, ma anche da chi vi è escluso”

Questa citazione si trova in un articolo su Economist del futurologo Paul Saffo, il quale afferma che la legge di Metcalfe si applica al contrario nel contesto di Facebook (e di tutti i social network). Leggi Facebook, Defined Networks, and the Inverse of Metcalfe’s Law (by Scott Karp).
La legge di Metcalfe è valida nei vecchi sistemi di rete, come la posta elettronica o la telefonia. Le reti sociali perdono valore quando vanno oltre una certa dimensione.
Già le reti sociali definite “ASMALLWORLD”, un luogo esclusivo per pochi eletti, si stanno moltiplicando. Ciù suggerisce che il futuro del social networking non sarà un unico grande grafo sociale, ma una miriade di piccole comunità.

In sintesi, la legge di Metcalfe applicata ai social network potrebbe addirittura agire al contrario se si supera il limite (purtroppo non prevedibile) di utenti in un gruppo/comunità.

Lavorare troppe ore è controproducente: facciamo un po’ di conti

Vi riporto un articolo di Joel Spolsky sulle sue riflessioni relative alle condizioni di forte stress e “sfruttamento” dei dipendenti di una società di informativa (di cui non cito il nome). Joel Spolsky è il fondatore della Fog Creek Software, una piccola ditta di software a New York. Laureato alla Università di Yale, ha lavorato come programmatore e manager presso Microsoft, Viacom e Juno. L’esempio si può benissimo adattare ai più svariati contesti lavorativi (non solo il campo informatico), specie dove si usa l’intelletto.

Esiste un’importante scuola di pensiero che riguarda il mondo dello sviluppo di software, di cui faccio parte, che afferma che i programmatori che lavorano per più di 40 ore la settimana per lunghi periodi di tempo sono meno produttivi di quelli che non sono chini sulla scrivania tutto il tempo. Questa teoria è esaminata e documentata in libri quali Peopleware di Timothy Lister e Tom DeMarco. Quando si è impegnati per più di otto ore al giorno in attività di programmazione, la qualità del lavoro prodotto viene compromessa a tal punto che è poi necessario dedicare due ore alla risoluzione dei bug per ogni ora trascorsa a scrivere codice. I risultati raggiunti dopo otto ore di lavoro sono infatti scadenti. Sono anche convinto che un dipendente con esperienza sia molto più valido di uno alle prime armi, e che un nuovo dipendente possa impiegare anche un anno per raggiungere il livello dei colleghi più esperti ed essere altrettanto produttivo. […]

Facciamo un po’ di conti. Se i programmatori sono obbligati a lavorare 90 ore la settimana, non possono sbrigare tutte quelle piccole commissioni che fanno parte della vita di tutti i giorni. Se sono al lavoro dalle 9.00 del mattino alle 10.00 di sera, 7 giorni su 7, quand’è che possono occuparsi del controllo delle emissioni per l’auto? Quand’è che possono pagare le bollette? O chiamare la mamma? Ve lo dico io quando: quando sono al lavoro. Tutte queste faccende vengono sbrigate durante l’orario di lavoro, quindi sottraiamo subito 10 ore di produttività dal totale della settimana. Bene, ora siamo scesi a 80 ore.

E le 40 ore di straordinari? Probabilmente sono inutili. Quasi tutti i programmatori obbligati a restare in ufficio fino a tarda sera utilizzano il tempo extra per navigare in Internet, chattare su IM o distrarsi con qualsiasi altro passatempo che non sia la scrittura di codice, e non perché siano pigri, ma perché il loro cervello chiude i battenti dopo un tot di ore di lavoro. […]

Supponiamo che per qualche ragione, prove alla mano, di queste 40 ore extra 10 vengano effettivamente dedicate alla scrittura di codice. A questo punto abbiamo 50 ore produttive. Ora aggiungiamo il costo di assunzione del personale per sostituire i lavoratori che si sono rovinati per il troppo lavoro. In genere, si stima che l’assunzione e la formazione di un nuovo dipendente costi all’incirca 12  mesi di retribuzione. Ciò include le spese di reclutamento, ma anche la minore produttività del nuovo dipendente mentre cerca di mettersi alla pari con i colleghi, il tempo che porta via agli altri dipendenti che devono intervistarlo e mostrargli tutto dopo l’assunzione, le spese di trasferimento, i premi di incentivazione, e altro ancora. […] Se vogliamo analizzare la situazione in base alle nostre 50 ore di lavoro settimanali, scendiamo a poco più di 25 ore produttive la settimana per lavoratore medio, perché quasi la metà dei dipendenti si trova ancora nel primo anno di lavoro e pertanto i costi iniziali non sono stati recuperati.

Settimane lavorative di 40 ore non solo sarebbero più umane, ma risulterebbero molto più proficue […]

[A proposito di softwareJoel Spolsky]