De absurde love i softwareverdenen

Har du nogensinde undret dig over, hvorfor smarte mennesker som softwareudviklere sviner det så ofte? Der er folk, der gjorde det. I dette indlæg gennemgår vi nogle af de uskrevne love, der beskriver professionelles adfærd af computere.

Min første computer var en Commodore 64. Omkring 30k RAM var til systemet, hvilket gav 32k til tekstbehandling, spil, regnskab for familievirksomheden og stort set alt andet, jeg laver på min 6gb computer nu. Det lader spørgsmålet stå åbent. Opfylder det nuværende udstyr softwarens behov, eller bruger softwaren flere hardwareressourcer, fordi de er tilgængelige?

Retfærdigvis er spillene ikke de samme, grafikken er heller ikke af samme kvalitet, og det ville have været umuligt at se film og lytte til musik. Det kan man dog ikke lade være med at tænke Der er programmer, der udgiver versioner og bruger flere og flere ressourcer uden egentlig at bidrage med noget nyt.

Her er årsagerne.

Zawinskis lov

Jamie Zawinsky, en udvikler hos Netscape, hævdede det hvert program inkorporerer funktioner, indtil det er i stand til at læse e-mails. Hvis det ikke lykkes ham, erstattes han af en anden, der er i stand til det.

Da han sagde det, var joken, at han henviste til programmer, der ikke oprindeligt var tænkt som mailklienter. Det holdt op med at være sjovt, da det blev opdaget, at mange apps på Google Play bad om tilladelse til at få adgang til telefonkomponenter og brugerdata, som de ikke behøvede for at udføre deres arbejde.

Nogle tolkede dette som en del af forsøg på at udspionere brugere. Men det er nok menneskets natur at gøre noget, simpelthen fordi det kan lade sig gøre.

Peters princip anvendt på software

Lawrence Peter blev berømt for at udtale, at i et hierarki rejser en person sig, indtil han når en position, som han er åbenlyst inkompetent til. Men han havde også tid til at sige noget om komplekse projekter:

"Et komplekst projekt vil blive for komplekst til at blive forstået selv af dets egne udviklere."

Princippet om mindste overraskelse

Udgivet i IBM Systems Journal i 1984, siger dette princip, at:

"Hvis en påkrævet funktion forårsager en stor overraskelse, kan det være nødvendigt at redesigne funktionen."

Med andre ord hvis en del af eller hele softwaren er meget forskellig fra, hvad brugeren var vant til, er den bedste ting at gøre et redesign. Idealet er at stræbe efter at opnå trinvise forbedringer, der er store nok til at være imponerende, men små nok til at forblive fortrolige for brugeren.

Ærgerligt, at Shuttleworth ikke tog højde for det, da han udgav Unity.

Lov om kybernetisk entomologi

Den første fejl (bug) i computerhistorien var ægte. En møl fløj ind i et af relæerne på en MARK II-computer og forårsagede en funktionsfejl.

Fortsat med metaforen, holder loven om kybernetisk entomologi det der vil altid være en fejl mere.

Det er noget, som alle computerbrugere ved. Uanset hvor meget et styresystem testes, er der altid en fejl, der opdages, når det er for sent.

Kernighans lov

Linux Adictos har et plugin installeret for at sikre, at vi forfattere skriver på en søgemaskinevenlig måde. Jeg hadede det fra dag ét. Ethvert forsøg på at skrive med en smule litterær flugt bliver straks fordømt med en rød cirkel. Som tiden gik, vænnede jeg mig til det, og jeg skal sjældent lave touch-ups.

Det samme sker for programmører, mange gange er de mere interesserede i at demonstrere deres evne til at kode end i at skrive enklere kode, der er lettere at forstå og vedligeholde.

Derfor fastholder Kernighans lov, at:

“Fejlretning er dobbelt så svært som at skrive koden i første omgang. Så hvis du skriver kode så smart som muligt, er du per definition ikke klog nok til at fejlsøge den."

90/90 reglen

Enhver, der nogensinde har startet et for-profit-projekt i det virkelige liv, ved, at hvert projekt vil tage dobbelt så lang tid og have dobbelt så meget som budgettet for at opnå halvdelen af ​​det forventede overskud.

Computerverdenen har sine varianter af denne lov. For eksempel sagde en Tom Cargill:

“De første 90 procent af koden repræsenterer de første 90 procent af udviklingstiden. De resterende 10 procent af koden står for de øvrige 90 procent af udviklingstiden."

Var det ikke klart? Måske vil Hofstadters lov hjælpe:

"Det tager altid længere tid, end du forventer, selv under hensyntagen til Hofstadters lov."

Jeg gætter på, at Ubuntu- og Fedora-udviklere skal vide det. Eller i det mindste huske det hver 6. måned.

Brooks lov

Open source softwareprojekter har normalt to problemer; finansiering og mangel på samarbejdspartnere. Medmindre det andet ikke er et problem. Ifølge Brook:

"Ved at tilføje arbejdskraft til et softwareprojekt, der kører forsinket, vil det sætte det yderligere tilbage."

Det er forståeligt. Det er ikke kun nye kodere, der skal sættes i gang. Der vil være mere at dokumentere, mere bureaukrati for at holde alle i sync, og der vil formentlig være slagsmål.

Og selvfølgelig kan vi ikke glemme vennen Parkinson og hans udtalelse om det Det er lige meget, hvor meget tomt du starter med. du vil altid have brug for mere. Han henviste til kontorplads, men det samme gælder RAM og diskplads.