Love indenfor softwareudvikling

Når man laver tilstrækkeligt mange fejl, vil de begynde at ophæve hinanden.

Jeg er ikke helt klar over, om den er ment optimistisk eller meget pessimistisk. Men den opstod på et tidspunkt, hvor jeg havde estimeret køretiden på et job til mere end 30 timer - jeg mente at fremgangsmåden var tåbelig (og jeg blev hånet for det af eksperterne). Køretiden viste sig at ligge omkring 36 timer. Det var en daglig kørsel. Efterhånden gik det op for mig, at stort set hvert eneste tal i min hurtige udregning var forkert. Men resultatet rigtigt nok.

Lederskab og forfremmelse er naturens måde at fjerne tåber fra produktionsforløbet.

Moores lov har absolut intet med hverken software eller softwareudvikling at gøre.

Jo da. Den gav rum for de vanvittige ideer med en grafisk brugergrænseflade. Det kostbare STAR-system var usælgeligt. Lisa'en så fed ud, men var dyr og som at slæbe lænker og en jernkugle efter sig. Mac'en kunne lige trække sig selv og Amiga'en var slet ikke ringe. Windows var den rene tortur.

Og pludselig b egyndte det hele at glide. På trods af at programmørerne blev ved med at læsse på. Og det på trods af Wirths Lov.

Men nu er vi ved at nå slutningen på dén epoke. Nu må vi til at tænke. Igen.

Fint snittet kål med sennepsdressing.
Den er ikke begrænset til softwareudvikling, men stadig lækker.

På mit arbejde, plejer jeg at sige at om fredagen tager Murphy i byen for fuld musik.

... Så den dag har jeg lidt mere travlt end normalt, fordi min jobbeskrivelse er lidt populært sagt at være en modvægt til ... Murphys Lov! ;-)

Amdahls lov er altid god at have in mente: https://en.wikipedia.org/wiki/Amdahl%27s_law - kort fortalt, så siger den, at jo mere af en opgave, som ikke kan parallelliseres, jo mindre udbytte vil der være af at tilføje flere processorer. Man kan sige, at sat på spidsen, så er "hvis en kvinde kan føde et barn på ni måneder, hvor langt tid vil ni kvinder så være om det" et eksempel. Vi taler selvfølgelig latency og ikke throughput, for ni kvinder kan føde ni gange så mange børn som en kvinde, hvis bare man giver dem tid nok.

Parkinsons lov: "work expands so as to fill the time available for its completion" https://en.wikipedia.org/wiki/Parkinson%27s_law opstod i studiet af offentlig forvaltning, og ser ud til at være tyrkertro hos de folk, som mener, at ethvert udbud skaber sin egen efterspørgsel. Det ser også ud til at gælde for udviklingsteams og for applikationer, selvom det er værd at overveje, om det ikke i virkeligheden er udtryk for en mængde af generelt uopfyldte behov som så reduceres en smule.

Metcalfes lov aka. "netværkseffekten" https://en.wikipedia.org/wiki/Metcalfe%27s_law siger at jo større et netværk er, jo større værdi har det også for deltagerne. Det bruges til at forklare fænomener som, at når de fleste af ens omgangskreds er på Facebook, så giver det også større værdi selv at være på Facebook. "Netværk" har derfor en naturlig tendens til at blive monopoler, og modsvaret er åbne standarder.

Jeg ved ikke hvem, som oprindeligt sagde det, men fejl som forsvinder af sig selv, har en uvane med at komme igen af sig selv. Og som regel på det mest ubelejlige tidspunkt. Som de siger i reklamerne: få det nu fikset!

... en mere uden kilde: alle opgaver, som bliver overset, er 100% underestimet.

Moores lov har ret meget betydning for softwareudvikling :-)

Er der ikke en omvendt propotionel lov omkring kvaliteten af koden vs CPUens regnekraft?

Kig bare på Windows operativsystemet. :-)

Dengang CPUen hed noget med 386 og kørte med 20 Mhz. DOS 5.0 og Windows 3.1 kunne være på 8-10 disketter á 1.44 MB stykker.

I dag har CPUen flere kerner og kan køre ved omkring 5 Ghz. En standard Windows installation kan nemt fylde 40 GB.

... og så har jeg ikke engang kigget på hvad Office pakken fylder. :-)

Jeg kan ikke helt komme med en god forklaring på hvorfor ting skal fylde så meget. :-)

Edsgar Dijkstra var god for et antal udtalelser, der uafhøngigt af hinanden af forskellige personer er blevet døbt "Dijkstra's Law". Her er et par eksempler:

"Program testing can be used to show the presence of bugs, but never to show their absence!"

"Simplicity is prerequisite for reliability."

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."

"A quantitative difference is also a qualitative difference if the quantitative difference is greater than an order of magnitude."

"Elegance is not a dispensable luxury but a quality that decides between success and failure."

Jeg kan ikke helt komme med en god forklaring på hvorfor ting skal fylde så meget. :-)

Fordi de kan. Windows bruger enorme ressourcer på at lave små smarte animationer, hver gang du trykker på en knap. En stor del af pladsen i en standard Windows installation er ikke kode, men grafiske elementer og lydfiler.

Er der ikke en omvendt propotionel lov omkring kvaliteten af koden vs CPUens regnekraft?

Nok ikke så enkelt. Men en større maskine (mere hovedlager, billigere baggrundslager og mere rå kraft) muliggør mere komplekse programmer/systemer. Noget blivet brugt til at løse nye problemer, meget bliver brugt til ... "lir". Resultatet af et større system bliver en masse krydsforbindelser, mærkelige og ukendte sammenhænge og utestede kombinationer.

Desuden er der ret mange nye opgaver i form af varianter af hardware, skærmstørrelser og ... som kræver hver sin specielle klump kode.

Hvem var det, der sagde, at "en programmør, der er god med en debugger, er en dårlig programmør"? Meningen var vist ikke, at man skal undgå debuggeren for enhver pris, men at man skal tænke før man kører debugger.

Hvem var det, der sagde, at "en programmør, der er god med en debugger, er en dårlig programmør"?

Jeg er nu mere imponeret over hvis en programmør kan holde styr på hele sin kode uden brug af debugger, når man kommer op i måleenheden "kloc" - og gerne med minimum 2-3 cifre før enhedsangivelsen.

... og endnu mere, hvis de har stadigvæk styr på koden 5 år nede af vejen, når der pludselig kommer ønsker om nye features - eller nogle har langt om længe opdaget en bug.

Generelt set:

Kan man lave en regel om, hvis man Er ude på 5. niveau af IF-sætninger, så er koden for kompleks? ;-)

"Design flaws travel in groups".

En engelsk filosof, William of Ockham (1285-1347), har "opfundet" en berømt lov - eller et princip, Ockhams Razor, som i det væsentligste angiver, at enklere formuleringer og løsninger er mere tilbøjelige til at være korrekte end komplekse.

The researchers did a test. They took a nice car, like a Jaguar, and parked it in the South Bronx in New York. They retreated back to a duck blind, and watched to see what would happen. They left the car parked there for something like four days, and nothing happened. It wasn't touched. So they went up and broke a little window on the side, and went back to the blind. In something like four hours, the car was turned upside down, torched, and stripped—the whole works.

They did more studies and developed a "Broken Window Theory." A window gets broken at an apartment building, but no one fixes it. It's left broken. Then something else gets broken. Maybe it's an accident, maybe not, but it isn't fixed either. Graffiti starts to appear. More and more damage accumulates. Very quickly you get an exponential ramp. The whole building decays. Tenants move out. Crime moves in. And you've lost the game. It's all over.

We use the broken window theory as a metaphor for managing technical debt on a project.

https://www.artima.com/intv/fixit2.html

Kan man lave en regel om, hvis man Er ude på 5. niveau af IF-sætninger, så er koden for kompleks? ;-)

https://en.wikipedia.org/wiki/Cyclomatic_complexity

Understående er ikke en lov, men jeg syntes alligevel det passede ind.

• The network is reliable.
• Latency is zero.
• Bandwidth is infinite.
• The network is secure.
• Topology doesn't change.
• There is one administrator.
• Transport cost is zero.
• The network is homogeneous.

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

Amdahls lov

Det er altid værd at huske at Amdahls Lov blev formuleret i en markedsføringskontekst hvor Amdahl udtalte sig om IBM's konkurrerende mainframe-arkitektur, som var langt mere parallel end Gene Ahmdals egen. Amdahls Lov passer naturligvis, men personligt synes jeg Gustafsons Lov er mere repræsentativ for hvordan vi bruger datamater, da denne omhandler hvordan vi kan løse større problemer på samme tid, i takt med at vores datamater bliver hurtigere.

Fik en kæmpe griner, da jeg så den her:
The fastest way to get help over the internet is not to ask the question but to instead answer it wrong.
Den holder 100 :)

Hvis der er en "lov" indenfor softwareudvikling som jeg hader, så er det den som er er kaldt Knuths lov eller Knuth's optimization principle. For gennem årene har jeg set den brugt til at retfærdigøre manglende omtanke.

Den er beskrevet som premature optimization is the root of all evil, men denne sætning er taget ud af kontekst. Det som Knuth skrev var:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Og pludseligt handler det om at tænke sig om. At identificere de kritiske 3%. Der hvor man skal tænke på optimering længe inden koden er skrevet. Eksempler er valg af datastrukturer eller distribuerede systemer.

Jeg er nu mere imponeret over hvis en programmør kan holde styr på hele sin kode uden brug af debugger

Giv en mand en kop kaffe, og han vil få varmen i en time.
Giv ham en debugger, og han vil svede resten af ugen.

En debugger et et glimrende værktøj, når man skal finde ud af detaljerne i noget rod. Men man bør prøve at pejle sig ind på problemstedet først. Ved at tænke over problemet og måske sætte nogle passende stykker sladrebeskeder ind i koden. At starte med en debugger svarer til at lave en udgravning med en teske.

En, der er god ved rundvisning under jobsamtaler men som jeg ikke har kilden på er

Der er omvendt proportionalitet mellem mængden af Dilbert striber hængt op på væggene og hvor godt udviklerne har det.

Der er ingen grund til at blive nedladende. Jeg ved udmærket hvad software er og hvad software gør. Jeg har udviklet software hver dag de sidste 20 år.

Ja software kører på hardware og dermed bestemmer hardware naturligvis hvor hurtigt software bliver afviklet.

Men Moores lov siger noget om tætheden af transistorer i hardware og hvordan tætheden udvikler sig over tid - den siger grundlæggende ikke noget om software eller udvikling af software.

Den havde jeg aldrig hørt om, men det er fedt at se den har et navn, for det er noget jeg flere gange har prøvet at opfordre til... desværre uden det store held.

I ved det med at pålægge al skyld for et programs dårligdomme på én syndebuk, og så sende vedkommende ud i ørkenen. Det løser naturligvis ikke problemerne med softwaren, men jeg har engang for længe siden oplevet en chef redde sin egen bagdel på den måde.

Men Moores lov siger noget om tætheden af transistorer i hardware og hvordan tætheden udvikler sig over tid - den siger grundlæggende ikke noget om software eller udvikling af software.

Det er principielt rigtigt, at enhver turing-komplet computer kan gøre det samme som enhver anden turing-komplet maskine. Givet man har ekstra lager nok og god tid. Man kunne simulere en brintbombe på en zx-80 på den måde (det ville være et stort fremskridt for nedrustningen). Men Moores lov giver nogle muligheder for i praksis at prøve nogle ting, man ikke kunne gøre førhen. Et IDE på Manchester Baby giver ikke megen mening. Den luksus at skrive lidt, kompilere, teste, skrive lidt mere/rette i stedet for at aflevere et job til kørsel i løbet af eftermiddagen, giver andre måder at udvikle på. Det er vist der, de ekstra transistorer har haft enorm betydning. Eller for at lave en parafrase på Marx: Transistorernes omslag i kvalitet.

Det er principielt rigtigt, at enhver turing-komplet computer kan gøre det samme som enhver anden turing-komplet maskine.

Men Moores lov er jo slet ikke så advanceret at vi behøver blande Turing ind i den.

Moores lov siger jo blot at udviklingen af processorer, i en periode, har været lineær og dermed forudsigelig.

Vi kunne jo snild have opnået samme transistortæthed hvis udviklingen have være ikke-lineær, var kommer i skvulp og Moores lov ikke havde været gældende. I så fald havde udviklingen ikke være forudsigelig men det har stadig intet med software eller softwareudvikling at gøre.

Men jeg har kigget kommentarerne igennem, og jeg kan ikke se at der skulle være noget nedladende i nogle af dem.

Det var måske forkert opfattet. :-) Når nogen begynder at 'forsikre' mig om noget, ogforklare mig hvad jeg kan bruge en mobiltelefon til så bliver jeg lidt træt.

Anyway, software har ikke nødvendigvis noget med Moores lov at gøre, da vi godt kunne have opnået samme transistortæthed hvis Moores lov ikke havde været gældende. Vi havde jo ikke nødvendigvis skulle nøjes med radiorør selvom udviklingen havde være ikke-lineær.

Moores lov siger jo blot at udviklingen af processorer, i en periode, har været lineær og dermed forudsigelig.

Du mener eksponentiel, ikke? Den er stadig forudsigelig. Eller har været det hidtil.

Du mener eksponentiel, ikke?

Jo selfølgelig. 'Doubles about every two years'. Det må være eksponentielt :-)

Takker!

Hofstadter's law is the observation that “It always takes longer than you expect, even when you take into account Hofstadter's Law.”

Jeg synes dette er meget relevant også for softwareudvikling...

ofstadter's law is the observation that “It always takes longer than you expect, even when you take into account Hofstadter's Law.”

Jeg synes dette er meget relevant også for softwareudvikling...

Ja, specielt fordi den er rekursiv.

Finagle's law of dynamic negatives (also known as Melody's law or Finagle's corollary to Murphy's law) is usually rendered as "Anything that can go wrong, will—at the worst possible moment."

Den havde jeg aldrig hørt om, men det er fedt at se den har et navn, for det er noget jeg flere gange har prøvet at opfordre til... desværre uden det store held.

Det er værd at læse The Harmful Consequences of Postel's Maxim :-)

"Measuring software development progress in lines of code is like measuring aircraft design progress in tonnes".

Jeg ville ønske, at Microsoft ville tage konsekvenserne af denne regel.

...har jeg også været fan af i mange år. Men det ser ud til at Scott Adams er blevet kuku på det seneste.

Han er sprunget ud som både klimafornægter, kæmpe Trump fan, Holocaust tvivler og meget andet sjovt.

Det gør selvfølgelig ikke nødvendigvis hans cartoons mindre sjove, men f.eks. det med klima har han formået at skrive ind i nogle af dem. Det gør, at jeg har det lidt svært ved at læse dem efterhånden.

https://rationalwiki.org/wiki/Scott_Adams

Nå - det var lidt off topic, men nu var der to der havde nævnt ham.