Che siate degli sviluppatori esperti o alle prime armi, ci sono delle leggi sullo sviluppo del software che possono essere utili a risolvere dei problemi a lavoro.
Adagi che possono sbloccare delle fasi di stallo sia che si lavori in gruppo o da soli.
Vogliamo condividere con voi un elenco di 15 leggi sullo sviluppo del software che trovate qui sotto.
Rasoio di Occam
Il Rasoio di Occam è un principio metodologico realizzato nel XIV secolo dal filosofo e frate francescano inglese William of Ockham, noto in italiano come Guglielmo di Occam.
La metafora del “rasoio” di Occam propone praticamente il seguente assunto: «a parità di fattori la spiegazione più semplice è da preferire».
Un principio che va a braccetto con il KISS, un acronimo usato in progettazione, che sta per Keep It Simple, Stupid, ossia “rimani sul semplice, stupido”.
In riferimento al codice sorgente di un programma significa non occuparsi delle ottimizzazioni fin dall’inizio, ma cercare invece di mantenere uno stile di programmazione semplice e lineare, demandando le ottimizzazioni al compilatore o a successive fasi dello sviluppo.
Rasoio di Hanlon
Sulla scia del Rasoio di Occam, il Rasoio di Hanlon, scritto intorno al 1980, recita così: «Non presumere mai cattiveria laddove basti la stupidità».
Non si parte dal principio che la gente sia cattiva ma semplicemente ignorante. Quindi sarà utile aiutarla a superare l’ignoranza.
Il principio di Pareto
Partendo dagli studi di Pareto del 1897, Joseph M. Juran formulò questo principio prevedendo che «la maggior parte degli effetti è dovuta a un numero ristretto di cause».
Vi sarà capitato di avere centinaia di errori durante lo sviluppo di un’applicazione. Vi sarà pure successo di risolvere uno dei problemi e di notare la scomparsa di molti errori segnalati in precedenza. Ecco il principio di Pareto in azione.
Effetto Dunning-Kruger
I ricercatori David Dunning e Justin Kruger condussero un esperimento nel 1999. I due studiosi hanno osservato il cosiddetto effetto Dunning-Kruger. Le persone senza competenze tendono a sopravvalutare le proprie capacità ritenendosi molto più competenti rispetto a quanto lo siano veramente.
Legge di Linus
Lo sviluppatore Eric S. Raymond scrisse questa legge dedicandola a Linus Torvalds: «Dato un numero sufficiente di occhi, tutti i bug vengono a galla».
In pratica, se non riuscite a trovare il problema, fatevi aiutare da qualcun altro. Attività come il pair programming funzionano bene in determinati contesti. Dopo tutto, spesso e volentieri, gli errori sono nel vostro codice.
Principio di robustezza (o Legge di Postel)
Una delle idee fondamentali nello sviluppo software, in particolare nell’ambito del design delle API, è il principio di robustezza: «sii conservatore in ciò che fai, sii Liberal in ciò che accetti dagli altri».
Questo principio è stato scritto da Jonathan Bruce Postel, informatico statunitense noto per aver scritto diversi RFC.
Legge di Eagleson
Avete abbandonato da tempo un progetto e quando rimettete mano al codice vi chiedete chi abbia scritto quell’obbrobrio e scoprite che siete stati voi?
La legge di Eagleson descrive bene questa situazione: «qualsiasi codice sorgente che hai scritto e che non è più stato guardato da sei o più mesi potrebbe benissimo essere stato scritto da qualcun altro».
Principio di Peter
Una legge che può essere applicata ai manager (di qualsiasi campo, non solo dello sviluppo software) è quella formulata dallo psicologo canadese Laurence J. Peter: «la selezione di un candidato per una posizione è basata sulla performance del suo ruolo attuale anziché sulle competenze utili per il ruolo previsto».
Il principio di Peter è spesso sintetizzato in maniera sarcastica con la frase «in una gerarchia, ogni dipendente tende a salire di grado fino al proprio livello di incompetenza».
Principio di Dilbert
Il cartonista Scott Adams, autore dei fumetti Dilbert, propose negli anni ’90 una variante negativa del principio di Peter secondo cui i lavoratori meno competenti sono promossi più velocemente.
Il principio può essere formulato così: «tra i lavoratori competenti, quelli incompetenti saranno promossi con posizioni manageriali, così da rimuoverli dall’attuale posizione e ridurre il danno che possono fare».
La legge di Hofstadter
Vi capita di notare che per fare qualcosa ci mettete sempre più tempo di quanto pensiate? Così Douglas Hofstadter scrisse il seguente principio: «per fare una cosa ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter».
La regola 90-90
C’è sempre qualcosa che va storto. Le persone generalmente difficilmente sanno stimare il proprio livello di competenza. Così Tom Cargill, ingegnere al Bell Labs negli anni ’80, scrisse il seguente principio in chiave ironica: «il 90% del codice richiede il 90% del tempo dedicato allo sviluppo. Il restante 10% del codice richiede il 90% del tempo».
Forse può aiutarci a capire perché molta progettazione software sfora il budget a disposizione ed è a corto di funzionalità.
La legge di Parkinson
«Il lavoro si espande fino a occupare tutto il tempo disponibile; più è il tempo e più il lavoro sembra importante e impegnativo». Così Cyril Northcote Parkinson scrisse nel 1958 il suo saggio secondo cui più tempo a disposizione si avrà, più se ne sprecherà.
Da ricordare per le vostre prossime stime temporali.
La legge di Sayre
Il docente ed economista Charles Issawi propose l’idea conosciuta come la Legge di Sayre, intitolata al docente della Columbia University.
Secondo Issawi, la formulazione è questa: «in ogni controversia l’intensità del sentimento è inversamente proporzionale al valore dell’argomento trattato».
In breve, più è insignificante qualcosa, più le persone dibatteranno animatamente su di esso.
Legge della banalità di Parkinson (o Bike shedding)
Sempre Parkinson scrive nel suo libro “La legge di Parkinson” anche il seguente principio, in chiave satirica e cinica: «il tempo speso su un argomento in agenda sarà inversamente proporzionale alla somma di denaro investito».
L’autore immagina una situazione in cui i partecipanti a una riunione per realizzare un reattore nucleare perdano più tempo a discutere della rimessa per le biciclette che nel definire le funzioni principali del reattore.
Tempo e opinioni sono spesi per idee che ognuno può capire ma che sono più banali.
La legge della comprensione argomentativa
Scritta dallo sviluppatore Matthew Jones, questo principio riassume la legge di Sayre e la legge della banalità di Parkinson.
«Più le persone capiscono qualcosa, più avranno il desiderio di discuterne e lo faranno con più determinazione».
Anche se non sono tutte leggi che si rifanno al campo informatico, ci permettono di porre l’accento sull’importanza delle competenze soft che ogni sviluppatore dovrebbe avere.
D’altronde, il software è scritto per le persone che dovranno usarlo e con cui dovranno interagire.
Se conosci altri principi, regole o leggi sullo sviluppo del software o altre attività che riguardano alcuni processi (valutazioni, meeting), scrivile adesso qui sotto nei commenti.
