Leggi di Murphy nello sviluppo del software

Da Nonciclopedia, l'enciclopedia libera...

Nerdissimi.PNG
Questo articolo è stato scritto da nerd!
Quindi tranquillo, non sei l'unico povero Cristo che non ha capito un'acca di quello che c'è scritto,
mettiti il cuore in pace, hai ancora una vita sociale e non puoi capire il nerdiano.
Provvederemo a farti diventare uno di loro.
Personaggio di Star Trek sclera davanti a schermo blu della morte.gif

Tipico programmatore che vede le leggi di Murphy nello sviluppo del software compiersi.


~ Programmatore sul proprio lavoro

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.


[modifica] Analisi dei requisiti

[modifica] 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.

[modifica] Legge di Grossman

I problemi più complessi hanno soluzioni semplici, facili da comprendere e sbagliate.

[modifica] Commento di J.S. Gillette sui requisiti

Il committente sa sempre quel che vuole, solo che continua a cambiare idea.

[modifica] Legge di Wethern

Tizio picchia un computer.gif

Prendersela con l'hardware è la cosa più sciocca da fare, ma picchiare il software non darebbe tanta soddisfazione.

La supposizione è la madre di tutte le boiate.

[modifica] Legge di Sevareid

La causa principale dei problemi sono le soluzioni.

[modifica] Paradosso di Capitan Ovvio

I requisiti a cui bisogna dare più importanza sono quelli che il cliente considera ovvi.

[modifica] 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.

[modifica] Documentazione

[modifica] Principio base della documentazione

Se tutto il resto fa fiasco, leggi la documentazione.

[modifica] 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.

[modifica] Legge dei diagrammi

I dettagli che mancano nei diagrammi sono quelli più importanti.

[modifica] Principio del codice autoesplicativo

L'autoesplicatività del codice decresce in proporzione esponenziale con il passare del tempo.

[modifica] Corollario

Tutti i programmatori sono convinti che il proprio codice sia autoesplicativo.

[modifica] Paradosso della documentazione

Più una funzionalità è ovvia, più è probabile che sia documentata.

[modifica] 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à.

[modifica] Programmazione

[modifica] Principio della perversità della programmazione

C'è sempre un altro bug.

[modifica] Legge della grande idea

L'unica volta che ti viene in mente una grande soluzione è dopo che qualcun altro ha già risolto il problema.

[modifica] Legge della rivelazione

Per quanto nascosto sia un bug, verrà sempre fuori nel momento peggiore.

[modifica] Terza legge di Greer

Un programma di computer fa quello che gli dici, non quello che vuoi.

[modifica] Principio dell'ananas applicato al software

Le componenti migliori di ogni software non saranno separabili dalle peggiori.

[modifica] Primo assioma di Leo Beiser sui file

Quando salvi un file, ricordati in che path l'hai salvato.

[modifica] 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.

[modifica] Principio di Eng sul software

Più è stato facile scriverlo, più la sua manutenzione sarà difficile.

[modifica] 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.

[modifica] Corollari

  • Il progettista modificherà il diagramma all'ultimo momento per seguire il pattern architetturale più recente.
  • Le modifiche non saranno indicate nella documentazione.

[modifica] Legge dei test

Bill Gates.jpg

Con lui tali leggi non funzionano, ha pagato tutti i giudici.

Più test vengono effettuati su un software, più bug troveranno gli utenti dopo il rilascio.

[modifica] Legge dell'idra

Il numero dei bug aumenta in proporzione esponenziale con il numero di patch applicate per correggerli.

[modifica] Legge della compatibilità (o legge di Internet Explorer)

C'è sempre almeno un browser in cui una funzionalità cross-browser non funzionerà come previsto.

[modifica] Legge della correzione

Il modo migliore di correggere un bug in una funzionalità complessa è riscriverla da zero.

[modifica] Paradosso della progettazione

Più perfetta è la progettazione, più durante la codifica sarà necessario improvvisare.

[modifica] Legge dell'upload

Mentre stai caricando un grosso file su un server, la connessione di rete cadrà.

[modifica] Corollario

Più il file è importante, più alta è la probabilità che, dopo l'upload, risulti danneggiato.

[modifica] Legge base dei linguaggi

Non c'è linguaggio di programmazione in cui sia difficile scrivere cattivi programmi.

[modifica] Massima di Zimmerman

Se una funzionalità è duplicata in più parti del programma, presenta bug in più parti del programma.

[modifica] Corollario

Si tratta sempre di bug diversi.

[modifica] Ciclo di Murphy per lo sviluppo del software

  1. Non funziona.
  2. Lo correggi.
  3. Funziona.
  4. Lo modifichi.
  5. Non funziona.

[modifica] Corollario

Alla fine quando hai finito di correggerlo ti dimenticherai come lo hai corretto e non salverai.

[modifica] Paradosso del porting

Ogni porting, ogni restyling, ogni migrazione di piattaforma, comporta un rifacimento completo.

[modifica] Progetti e management

[modifica] Legge di Wolter

Se c'è tempo non ci sono i soldi. Se ci sono i soldi non c'è tempo.

[modifica] Corollario

Il numero di compiti contemporanei assegnati ai programmatori aumenta in proporzione esponenziale al diminuire di entrambi.

[modifica] Legge di Brooks

Più programmatori vengono aggiunti a un progetto in ritardo, più il ritardo aumenterà.

[modifica] Legge di Van Gogh

Qualunque progetto tu abbia, ci sarà una qualche difficoltà nascosta da qualche parte.

[modifica] Legge di Oppenheimer

L'esperienza istantanea non esiste.

[modifica] Le fasi di un progetto

  • Entusiasmo.
  • Disillusione.
  • Panico.
  • Ricerca del colpevole.
  • Punizione dell'innocente.
  • Gloria e onori ai non partecipanti.

[modifica] Legge di Ginsberg

La maggior parte delle riunioni serve a decidere quando si terrà la prossima riunione.

[modifica] Legge di Shapiro sul riconoscimento

Chi fa di meno riceverà più complimenti.

[modifica] Legge di Strano

Quando tutti il resto fa fiasco, prova a fare come dice il capo.

[modifica] Quarta legge di Frothingham

L'urgenza varia inversamente all'importanza.

[modifica] Seconda legge di Brintall

Se ti danno due ordini contraddittori, obbedisci a entrambi.

[modifica] Regola di Winger

Se rimane sulla tua scrivania per più di 15 minuti, sei diventato un esperto.

[modifica] Assioma di Aigner

Per quanto bene tu possa eseguire un lavoro, ci sarà un superiore che ne vorrà modificare il risultato.

[modifica] Dilemma del genio

Nessun capo terrà mai un impiegato che ha sempre ragione.

[modifica] Dilemma finanziario di Bob

Costa sempre più del previsto.

[modifica] Regola di Bralek per il successo

Fidati solo di chi rischia di perdere quanto te, se le cose vanno male.

[modifica] 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.

[modifica] Corollario

Se non ci fosse l'ultimo momento, non si riuscirebbe a fare niente.

[modifica] Legge di Knagg

Più grandioso è il progetto, più alta è la possibilità di fallimento.

[modifica] Teoria della supervisione selettiva

L'unica volta in una giornata che vi concedete un attimo di riposo è la volta che il capufficio vi guarda.

[modifica] Legge base del management

Il Project Manager è una persona che pensa che 9 donne riusciranno a fare un bambino in 1 mese.

[modifica] Corollario

Se hanno esperienza, possono fare 3 gemelli in 2 settimane.

[modifica] Paradosso del piano

Più un piano è perfetto, più è probabile che fallisca al primo imprevisto.

[modifica] Corollario

I peggiori pianificatori sono gli ottimisti.

[modifica] Lemma TSPR

Tizio distrugge un PC col martello.gif

Alla fine c'è solo una cosa da fare: cambiare lavoro.

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.

[modifica] Leggi base degli straordinari

  • Un giorno solo contiene una quantità infinita di ore di straordinario.
  • Lo straordinario a recupero non sarà mai recuperabile.

[modifica] 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.

[modifica] Della stessa collana

Strumenti personali
wikia