Leggi di Murphy nello sviluppo del software
Le leggi di Murphy nello sviluppo del software sono una pericolosa calamità naturale, nata per far passare le peggiori notti insonni ai programmatori di tutto il mondo. Perchè sanno bene che quando tutto sembra funzionare, quando il risultato sembra essere quello giusto, è proprio allora che sta per arrivare la catastrofe.
Analisi dei requisiti
Leggi di Manubay per i programmatori
- Se la modifica di un programmatore a un programma esistente funziona, probabilmente non era quello che voleva il cliente.
- Il cliente non sa quello che vuole, ma sa quello che non vuole.
Legge di Grossman
I problemi più complessi hanno soluzioni semplici, facili da comprendere e sbagliate.
Commento di J.S. Gillette sui requisiti
Il committente sa sempre quel che vuole, solo che continua a cambiare idea.
Legge di Wethern
La supposizione è la madre di tutte le boiate.
Legge dei diagrammi
I dettagli che mancano nei diagrammi sono quelli più importanti.
Legge di Sevareid
La causa principale dei problemi sono le soluzioni.
Paradosso di Capitan Ovvio
I requisiti a cui bisogna dare più importanza sono quelli che il cliente considera ovvi.
Programmazione
Principio della perversità della programmazione
C'è sempre un altro bug.
Legge della grande idea
L'unica volta che ti viene in mente una grande soluzione è dopo che qualcun altro ha già risolto il problema.
Legge della rivelazione
Per quanto nascosto sia un bug, verrà sempre fuori nel momento peggiore.
Terza legge di Greer
Un programma di computer fa quello che gli dici, non quello che vuoi.
Principio dell'ananas applicato al software
Le componenti migliori di ogni software non saranno separabili dalle peggiori.
Primo assioma di Leo Beiser sui file
Quando salvi un file, ricordati in che path l'hai salvato.
Corollari
Quando ti serve aprire un file:
- ti sarai dimenticato in che path l'avevi salvato;
- sarà su un supporto non più disponibile;
- sarà stato salvato in corrispondenza di cluster danneggiati;
- non avrai nessun programma in grado di aprirlo.
Principio di Eng sul software
Più è stato facile scriverlo, più la sua manutenzione sarà difficile.
Leggi di Gore applicata al software
- La funzione primaria del progettista è di rendere la vita difficile al programmatore e impossibile all'utente.
- La funzionalità contenente più bug di un software sarà localizzata nel file meno accessibile, o in più file in path molto diversi.
- Ogni progetto deve contenere almeno una componente obsoleta, due impossibili da implementare e tre che sono ancora in fase di sviluppo.
Corollari
- Il progettista modificherà il diagramma all'ultimo momento per seguire il pattern architetturale più recente.
- Le modifiche non saranno indicate nella documentazione.
Legge dei test
Più test vengono effettuati su un software, più bug troveranno gli utenti dopo il rilascio.
Legge dell'idra
Il numero dei bug aumenta in proporzione esponenziale con il numero di patch applicate per correggerli.
Legge della compatibilità
C'è sempre almeno un browser in cui una funzionalità cross-browser non funzionerà come previsto.
Legge della correzione
Il modo migliore di correggere un bug in una funzionalità complessa è riscriverla da zero.
Paradosso della progettazione
Più perfetta è la progettazione, più durante la codifica sarà necessario improvvisare.
Legge dell'upload
Mentre stai caricando un grosso file su un server, la connessione di rete cadrà.
Legge base dei linguaggi
Non c'è linguaggio di programmazione in cui sia difficile scrivere cattivi programmi.
Progetti e management
Legge di Wolter
Se c'è tempo non ci sono i soldi. Se ci sono i soldi non c'è tempo.
Legge di Brooks
Più programmatori vengono aggiunti a un progetto in ritardo, più il ritardo aumenterà.
Legge di Van Gogh
Qualunque progetto tu abbia, ci sarà una qualche difficoltà nascosta da qualche parte.
Legge di Oppenheimer
L'esperienza istantanea non esiste.
Le fasi di un progetto
- Entusiasmo.
- Disillusione.
- Panico.
- Ricerca del colpevole.
- Punizione dell'innocente.
- Gloria e onori ai non partecipanti.
Legge di Ginsberg
La maggior parte delle riunioni serve a decidere quando si terrà la prossima riunione.
Legge di Shapiro sul riconoscimento
Chi fa di meno riceverà più complimenti.
Legge di Strano
Quando tutti il resto fa fiasco, prova a fare come dice il capo.
Quarta legge di Frothingham
L'urgenza varia inversamente all'importanza.
Seconda legge di Brintall
Se ti danno due ordini contraddittori, obbedisci a entrambi.
Regola di Winger
Se rimane sulla tua scrivania per più di 15 minuti, sei diventato un esperto.
Assioma di Aigner
Per quanto bene tu possa eseguire un lavoro, ci sarà un superiore che ne vorrà modificare il risultato.
Dilemma del genio
Nessun capo terrà mai un impiegato che ha sempre ragione.
Dilemma finanziario di Bob
Costa sempre più del previsto.
Regola di Bralek per il successo
Fidati solo di chi rischia di perdere quanto te, se le cose vanno male.
Legge di Edward
Sforzo moltiplicato per tempo è uguale a una costante:
- Dato all'inizio un tempo lungo per fare qualcosa, lo sforzo iniziale sarà modesto.
- Quando il tempo si riduce a zero, lo sforzo tende all'infinito.
Corollario
Se non ci fosse l'ultimo momento, non si riuscirebbe a fare niente.
Legge di Knagg
Più grandioso è il progetto, più alta è la possibilità di fallimento.
Teoria della supervisione selettiva
L'unica volta in una giornata che vi concedete un attimo di riposo è la volta che il capufficio vi guarda.
Legge base del management
Il Project Manager è una persona che pensa che 9 donne riusciranno a fare un bambino in 1 mese.
Corollario
Se hanno esperienza, possono fare 3 gemelli in 2 settimane.
Primo paradosso di Fourier
Quando il tempo rimanente alla deadline tende a zero, lo sforzo per completare il progetto tende all'infinito.
Corollario
Il numero di ore di straordinario aumenta in proporzione esponenziale con la probabilità che il progetto fallisca.