De absurde wetten van de softwarewereld

Heb je je ooit afgevraagd waarom slimme mensen zoals softwareontwikkelaars het zo vaak verknoeien? Er zijn mensen die dat wel deden. In dit bericht bespreken we enkele van de ongeschreven wetten die het gedrag van professionals beschrijven van computers.

Mijn eerste computer was een Commodore 64. Bijna 30 kb RAM was voor het systeem, waardoor 32 kb overbleef voor tekstverwerking, gaming, boekhouding voor familiebedrijven en zo ongeveer alles wat ik doe met de 6 GB computer die ik nu bezit. Dat laat de vraag open Reageert de huidige apparatuur op de behoeften van software of gebruikt de software meer hardwarebronnen omdat deze beschikbaar zijn?

Eerlijk gezegd zijn de games niet hetzelfde, de graphics zijn niet van dezelfde kwaliteit en het zou onmogelijk zijn geweest om films te kijken en naar muziek te luisteren. Men kan het echter niet helpen, maar denk dat er zijn programma's die versies uitbrengen en steeds meer bronnen verbruiken zonder echt iets nieuws bij te dragen.

Hier zijn de oorzaken.

De wet van Zawinsky

Netscape-ontwikkelaar Jamie Zawinsky voerde dat aan Elk programma bevat functies totdat het e-mails kan lezen. Lukt dat niet, dan wordt hij vervangen door een ander die daartoe in staat is.

Toen hij het zei, was de grap dat hij doelde op programma's die oorspronkelijk niet bedoeld waren als e-mailclients. Het was niet meer grappig toen werd ontdekt dat veel apps op Google Play toestemming vroegen voor toegang tot telefooncomponenten en gebruikersgegevens die ze niet nodig hadden om hun werk te doen.

Sommigen interpreteerden dit als onderdeel van pogingen om gebruikers te bespioneren. Maar het is waarschijnlijk de menselijke natuur om iets te doen, simpelweg omdat het kan.

Peter's principe toegepast op software

Lawrence Peter werd beroemd omdat hij beweerde dat een persoon in een hiërarchie opstijgt naar een positie waarvoor hij buitengewoon incompetent is. Maar hij had ook tijd om iets te zeggen over complexe projecten:

"Een complex project wordt te complex om zelfs door zijn eigen ontwikkelaars te worden begrepen."

Beginsel van de minste verbazing

Dit principe, gepubliceerd in het IBM Systems Journal in 1984, stelt het volgende:

"Als een vereiste functie voor een grote verrassing zorgt, moet de functie mogelijk opnieuw worden ontworpen."

En otras palabras, als een deel of alle software erg verschilt van wat de gebruiker gewend was, is het beste een herontwerp​ Streef er idealiter naar om te bereiken incrementele verbeteringen die groot genoeg zijn om indrukwekkend te zijn, maar klein genoeg om vertrouwd te blijven voor de gebruiker.

Jammer dat Shuttleworth er geen rekening mee hield toen het Unity lanceerde.

Cybernetische entomologierecht

De eerste bug in de computergeschiedenis was echt. Een mot vloog in een van de relais van een MARK II-computer en veroorzaakte een storing.

Om verder te gaan met de metafoor, stelt de wet van cybernetische entomologie dat er zal altijd nog een bug zijn.

Dat is iets dat alle computergebruikers weten. Ongeacht hoeveel een besturingssysteem wordt getest, er is altijd een fout die wordt ontdekt als het te laat is.

De wet van Kernighan

Linux Adictos heeft een plug-in geïnstalleerd om ervoor te zorgen dat wij als auteurs zoekmachinevriendelijk schrijven. Ik haatte het vanaf dag één. Elke poging om met een beetje literaire vlucht te schrijven wordt onmiddellijk met een rode cirkel aan de kaak gesteld. Naarmate de tijd verstreek, raakte ik eraan gewend en hoef ik zelden bij te werken.

Hetzelfde gebeurt met programmeurs, vaak zijn ze meer geïnteresseerd in het demonstreren van hun vermogen om te coderen dan in het schrijven van een eenvoudigere code die gemakkelijker te begrijpen en te onderhouden is.

Daarom stelt de wet van Kernighan dat:

Foutopsporing is in de eerste plaats twee keer zo moeilijk als het schrijven van de code. Dus als je de code zo slim mogelijk schrijft, ben je niet per definitie slim genoeg om deze te debuggen. '

De 90/90 regel

Iedereen die in het echte leven een project met winstoogmerk is begonnen, weet dat elk project twee keer zo lang gaat duren en twee keer zoveel kost als begroot, om de helft van de verwachte winst te maken.

De computerwereld kent zijn varianten op deze wet. Een Tom Cargill zei bijvoorbeeld:

“De eerste 90 procent van de code vertegenwoordigt de eerste 90 procent van de ontwikkeltijd. De overige 10 procent van de code vertegenwoordigt de overige 90 procent van de ontwikkeltijd.

Was het niet duidelijk? Misschien helpt de wet van Hofstadter:

'Het duurt altijd langer dan je verwacht, zelfs met de wet van Hofstadter in gedachten.'

Ik denk dat ontwikkelaars van Ubuntu en Fedora het moeten weten. Of onthoud het tenminste elke 6 maanden.

Brook's Law

Open source softwareprojecten hebben vaak twee problemen; financiering en gebrek aan medewerkers. Tenzij de tweede geen probleem is. Volgens Brook:

"Het toevoegen van arbeid aan een softwareproject dat achterloopt op schema, zal het verder vertragen."

Het is begrijpelijk dat u niet alleen de nieuwe encoders hoeft bij te werken. Er zal meer moeten worden gedocumenteerd, er zal meer bureaucratie nodig zijn om iedereen synchroon te houden, en er zullen waarschijnlijk ruzies komen.

En natuurlijk mogen we vriend Parkinson en zijn bewering dat niet vergeten Het maakt niet uit met hoeveel lege ruimte u begint. Je hebt altijd meer nodig​ Hij doelde op kantoorruimte, maar hetzelfde geldt voor RAM en schijfruimte.