Le assurde leggi del mondo del software

Ti sei mai chiesto perché persone intelligenti come gli sviluppatori di software rovinano tutto così spesso? Ci sono persone che l'hanno fatto. In questo post esaminiamo alcune delle leggi non scritte che descrivono il comportamento dei professionisti dell'informatica.

Il mio primo computer era un Commodore 64. Quasi 30 kb di RAM erano per il sistema, lasciando 32 kb per l'elaborazione di testi, i giochi, la contabilità aziendale di famiglia e quasi tutto ciò che faccio con il computer da 6 GB che possiedo. Ciò lascia aperta la questione L'attrezzatura odierna risponde alle esigenze del software o il software utilizza più risorse hardware perché sono disponibili?

In tutta onestà, i giochi non sono gli stessi, la grafica non è della stessa qualità e sarebbe stato impossibile guardare film e ascoltare musica. Tuttavia, non si può fare a meno di pensarlo ci sono programmi che rilasciano versioni e consumano sempre più risorse senza apportare realmente nulla di nuovo.

Ecco le cause.

Legge di Zawinsky

Lo ha sostenuto lo sviluppatore di Netscape Jamie Zawinsky Ogni programma incorpora funzionalità fino a quando non è in grado di leggere le e-mail. Se non ci riesce, viene sostituito da qualcun altro in grado di farlo.

Quando lo disse, lo scherzo era che si riferiva a programmi che non erano originariamente intesi come client di posta elettronica. Ha smesso di essere divertente quando si è scoperto che molte app su Google Play chiedevano il permesso di accedere a componenti del telefono e dati utente di cui non avevano bisogno per svolgere il loro lavoro.

Alcuni lo hanno interpretato come parte dei tentativi di spiare gli utenti. Ma probabilmente è nella natura umana fare qualcosa semplicemente perché può essere fatto.

Il principio di Peter applicato al software

Lawrence Peter è diventato famoso per aver affermato che in una gerarchia una persona raggiunge una posizione per la quale è grossolanamente incompetente. Ma ha anche avuto il tempo di dire qualcosa sui progetti complessi:

"Un progetto complesso diventerà troppo complesso per essere compreso anche dai suoi stessi sviluppatori".

Principio del minimo stupore

Pubblicato nell'IBM Systems Journal nel 1984, questo principio afferma che:

"Se una funzione richiesta provoca una grande sorpresa, potrebbe essere necessario riprogettarla".

In altre parole, se una parte o tutto il software è molto diverso da quello a cui l'utente era abituato, la cosa migliore è una riprogettazione. Idealmente, sforzati di raggiungere miglioramenti incrementali che sono abbastanza grandi da essere impressionanti, ma abbastanza piccoli da rimanere familiari per l'utente.

Peccato che Shuttleworth non ne abbia tenuto conto quando ha lanciato Unity.

Legge sull'entomologia cibernetica

Il primo bug nella storia del computer era reale. Una falena è volata in uno dei relè di un computer MARK II causando un malfunzionamento.

Continuando con la metafora, la legge dell'entomologia cibernetica lo sostiene ci sarà sempre un altro bug.

Questo è qualcosa che tutti gli utenti di computer sanno. Non importa quanto un sistema operativo venga testato, c'è sempre un difetto che viene scoperto quando è troppo tardi.

Legge di Kernighan

Linux Adictos ha un plugin installato per garantire che noi autori scriviamo in modo ottimizzato per i motori di ricerca. L'ho odiato dal primo giorno. Ogni tentativo di scrivere con un po' di volo letterario viene subito denunciato con un cerchietto rosso. Col passare del tempo mi sono abituato e raramente devo fare ritocchi.

La stessa cosa accade ai programmatori, molte volte sono più interessati a dimostrare la loro capacità di codificare che a scrivere un codice più semplice che è più facile da capire e mantenere.

Quindi la legge di Kernighan afferma che:

Il debug è due volte più difficile della scrittura del codice in primo luogo. Quindi, se scrivi il codice nel modo più intelligente possibile, non sei, per definizione, abbastanza intelligente da eseguirne il debug. '

La regola del 90/90

Chiunque abbia avviato un progetto a scopo di lucro nella vita reale sa che ogni progetto richiederà il doppio del tempo e costerà il doppio di quanto preventivato, per realizzare la metà del profitto atteso.

Il mondo dei computer ha le sue varianti di questa legge. Ad esempio, un certo Tom Cargill ha detto:

“Il primo 90 percento del codice rappresenta il primo 90 percento del tempo di sviluppo. Il restante 10 percento del codice rappresenta il restante 90 percento del tempo di sviluppo ".

Non era chiaro? Forse la legge di Hofstadter aiuterà:

"Ci vuole sempre più tempo del previsto, anche tenendo a mente la legge di Hofstadter".

Immagino che gli sviluppatori di Ubuntu e Fedora debbano saperlo. O almeno ricordalo ogni 6 mesi.

Legge di Brook

I progetti di software open source hanno spesso due problemi; finanziamento e mancanza di collaboratori. A meno che il secondo non sia un problema. Secondo Brook:

"L'aggiunta di manodopera a un progetto software in ritardo sulla pianificazione lo ritarderà ulteriormente".

Comprensibilmente, non devi solo aggiornare i nuovi codificatori. Dovrà essere documentato di più, ci vorrà più burocrazia per mantenere tutti sincronizzati e probabilmente ci saranno litigi.

E ovviamente non possiamo dimenticare l'amico Parkinson e la sua affermazione Non importa quanto spazio vuoto inizi. Avrai sempre bisogno di più. Si riferiva allo spazio ufficio, ma lo stesso vale per la RAM e lo spazio su disco.