De absurda lagarna i programvaruvärlden

Har du någon gång undrat varför smarta människor som mjukvaruutvecklare krånglar så ofta? Det finns folk som gjort det. I det här inlägget recenserar vi några av de oskrivna lagarna som beskriver yrkesverksammas beteende av datoranvändning.

Min första dator var en Commodore 64. Cirka 30k RAM var för systemet, vilket lämnade 32k för ordbehandling, spel, redovisning av familjeföretaget och i stort sett allt annat jag gör på min 6GB-dator nu. Det lämnar frågan öppen. Uppfyller den nuvarande utrustningen programvarans behov, eller använder programvaran mer hårdvaruresurser eftersom de är tillgängliga?

I rättvisans namn är spelen inte samma sak, grafiken är inte heller av samma kvalitet och det hade varit omöjligt att se film och lyssna på musik. Däremot kan man inte låta bli att tänka så Det finns program som släpper versioner och förbrukar allt mer resurser utan att egentligen bidra med något nytt.

Här är orsakerna.

Zawinskis lag

Jamie Zawinsky, en utvecklare på Netscape, hävdade det varje program innehåller funktioner tills det kan läsa e-post. Om han inte lyckas ersätts han av en annan som är kapabel till det.

När han sa det var skämtet att han syftade på program som från början inte var avsedda som e-postklienter. Det slutade vara roligt när det upptäcktes att många appar på Google Play bad om tillåtelse att komma åt telefonkomponenter och användardata som de inte behövde för att göra sitt jobb.

Vissa tolkade detta som en del av försöken att spionera på användare. Men det ligger nog i människans natur att göra något bara för att det går att göra.

Peters princip tillämpas på mjukvara

Lawrence Peter blev känd för att påstå att i en hierarki reser sig en person tills han når en position som han är uppenbart inkompetent för. Men han hann också säga något om komplexa projekt:

"Ett komplext projekt kommer att bli för komplext för att kunna förstås även av dess egna utvecklare."

Principen om minsta överraskning

Denna princip, publicerad i IBM Systems Journal 1984, säger att:

"Om en nödvändig funktion orsakar en stor överraskning kan det bli nödvändigt att göra om funktionen."

Med andra ord, om en del av eller hela programvaran skiljer sig mycket från vad användaren var van vid, är det bästa att göra en omdesign. Idealet är att sträva efter att uppnå inkrementella förbättringar som är tillräckligt stora för att vara imponerande, men tillräckligt små för att förbli bekanta för användaren.

Synd att Shuttleworth inte tog hänsyn till det när han släppte Unity.

Lagen om cybernetisk entomologi

Den första buggen (buggen) i datorhistorien var verklig. En mal flög in i ett av reläerna på en MARK II-dator och orsakade ett fel.

För att fortsätta med metaforen, håller lagen om cybernetisk entomologi det det kommer alltid att finnas en bugg till.

Det är något som alla datoranvändare vet. Oavsett hur mycket ett operativsystem testas finns det alltid en bugg som upptäcks när det är för sent.

Kernighans lag

Linux Adictos har ett plugin installerat för att säkerställa att vi författare skriver på ett sökmotorvänligt sätt. Jag hatade det från dag ett. Varje försök att skriva med lite litterär flykt fördöms omedelbart med en röd cirkel. Med tiden vände jag mig vid det och jag behöver sällan göra bättringar.

Samma sak händer med programmerare, många gånger är de mer intresserade av att visa sin förmåga att koda än att skriva enklare kod som är lättare att förstå och underhålla.

Därför säger Kernighans lag att:

“Felsökning är dubbelt så svårt som att skriva koden i första hand. Så om du skriver kod så smart som möjligt är du per definition inte smart nog att felsöka den."

90/90-regeln

Alla som någonsin har startat ett vinstdrivande projekt i verkligheten vet att varje projekt kommer att ta dubbelt så lång tid och ha dubbelt så mycket som budgeterat, för att göra hälften av den förväntade vinsten.

Datorvärlden har sina varianter av denna lag. Till exempel sa en Tom Cargill:

"De första 90 procenten av koden representerar de första 90 procenten av utvecklingstiden. De återstående 10 procenten av koden står för de övriga 90 procenten av utvecklingstiden."

Var det inte klart? Kanske kan Hofstadters lag hjälpa:

"Det tar alltid längre tid än man förväntar sig, även om man tar hänsyn till Hofstadters lag."

Jag antar att Ubuntu och Fedora-utvecklare måste veta. Eller åtminstone kom ihåg det var sjätte månad.

Brooks lag

Programvaruprojekt med öppen källkod har vanligtvis två problem; finansiering och brist på samarbetspartners. Om inte det andra inte är ett problem. Enligt Brook:

"Att lägga till arbetskraft till ett programvaruprojekt som löper efter schemat kommer att sätta tillbaka det ytterligare."

Det är förståeligt. Det är inte bara nya kodare som måste få fart. Det kommer att finnas mer att dokumentera, mer byråkrati för att hålla alla i synka, och det kommer förmodligen att bli slagsmål.

Och naturligtvis kan vi inte glömma vännen Parkinson och hans uttalande om det Det spelar ingen roll hur mycket tomt utrymme du börjar med. du kommer alltid att behöva mer. Han syftade på kontorsutrymme, men detsamma gäller RAM och diskutrymme.