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 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.
Corollario
Se un cliente ti contesta il fatto che il gatto che gli hai portato non va a benzina, è perché "ovviamente" intendeva un gatto delle nevi.
Documentazione
Principio base della documentazione
Se tutto il resto fa fiasco, leggi la documentazione.
Corollari
- La documentazione non sarà mai stata scritta.
- Se è stata scritta, non descrive la funzionalità su cui stai lavorando.
- Se la descrive, è obsoleta.
- Se la descrive e non è obsoleta, è andata persa.
Legge dei diagrammi
I dettagli che mancano nei diagrammi sono quelli più importanti.
Principio del codice autoesplicativo
L'autoesplicatività del codice decresce in proporzione esponenziale con il passare del tempo.
Corollario
Tutti i programmatori sono convinti che il proprio codice sia autoesplicativo.
Paradosso della documentazione
Più una funzionalità è ovvia, più è probabile che sia documentata.
Corollari
- Le parti essenziali e ostiche non saranno mai documentate.
- Se un metodo si chiama "sbigullà", la sua documentazione sarà ridotta alla frase fa sbigullà.
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 applicate 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à (o legge di Internet Explorer)
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à.
Corollario
Più il file è importante, più alta è la probabilità che, dopo l'upload, risulti danneggiato.
Legge base dei linguaggi
Non c'è linguaggio di programmazione in cui sia difficile scrivere cattivi programmi.
Massima di Zimmerman
Se una funzionalità è duplicata in più parti del programma, presenta bug in più parti del programma.
Corollario
Si tratta sempre di bug diversi.
Ciclo di Murphy per lo sviluppo del software
- Non funziona.
- Lo correggi.
- Funziona.
- Lo modifichi.
- Non funziona.
Corollario
Alla fine, quando hai finito di correggerlo:
- Tentando di salvare, l'editor andrà in crash, facendoti perdere tutte le modifiche;
- Ti dimenticherai come lo avevi corretto;
- Ti accorgerai che è venerdì sera, e ti toccherà rifare tutto nel weekend (gratis).
Paradosso del porting
Ogni porting, ogni restyling, ogni migrazione di piattaforma, comporta un rifacimento completo.
Progetti e management
Legge di Wolter
Se c'è tempo non ci sono i soldi. Se ci sono i soldi non c'è tempo.
Corollario
Il numero di compiti contemporanei assegnati ai programmatori aumenta in proporzione esponenziale al diminuire di entrambi.
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.
Paradosso del piano
Più un piano è perfetto, più è probabile che fallisca al primo imprevisto.
Corollario
I peggiori pianificatori sono gli ottimisti.
Lemma TSPR
Più speri che i tuoi superiori, per portare avanti un nuovo progetto, mettano a disposizione
- Tempo;
- Soldi;
- Personale;
- Risorse;
più è probabile che lo debba completare
- Tu;
- da Solo;
- alla Perfezione;
- Rapidamente.
Leggi base degli straordinari
- Un giorno solo contiene una quantità infinita di ore di straordinario.
- Lo straordinario a recupero non sarà mai recuperabile.
Lemmi del ritardo
- Se sei in anticipo, il requisito sarà completamente ridefinito.
- Se sei in linea con i tempi, la scadenza sarà anticipata.
- Se sei in ritardo, accadranno entrambe le cose.
Paradosso dell'urgenza
Più è urgente una tua richiesta, più è probabile che sia cestinata.
Legge del colpevole
Se un programma non funziona, il colpevole sei tu:
- Se l'hai scritto tu dieci anni fa e qualcun altro l'ha riscritto, avresti dovuto verificare.
- Se l'ha scritto qualcun altro del tuo team, avresti dovuto verificare.
- Se hai verificato ed era tutto a posto, avresti dovuto verificare meglio.
Corollario
Dovrai sistemarlo tu, gratuitamente, e senza discutere.