Clojurians Log v2
clojure-norway
Morn
Mornings!
Morn!
Morn!
god morgen!
Morn!
Jeg skal presentere på konferanse på fredag denne uka! Konferansen er gratis og online. Innlegget mitt tar cirka en halvtime. I et tidligere liv, dimensjonerte jeg bygg. Av ekte ting som står i dag kan jeg dra fram https://www.strawberry.no/hotell/norge/oslo/clarion-hotel-the-hub/ (Oslo) sentrum og maskinsalen til kraftverket https://no.wikipedia.org/wiki/Lysebotn_II_kraftverk (Rogaland). https://www.vegvesen.no/vegprosjekter/europaveg/e39stordos/fjordkryssing-bjornafjorden/ (Vestland) avventer politiske prosesser før man bruker 15-25 milliarder på prosjektet. Når man regner på fysiske størrelser som millimeter, sekunder og kilonewton, blir enheten svært viktig. Riktig enhet gir intuisjon: foretrekker du å lese 1.8 tonn eller 0.0000018 gram? Og feil enhet lager ganske enkelt feil resultat: Skal vi gangeopp en "stoffkonsentrasjon" oppgitt i milligram per kubikkmillimeter med et volum i liter, kan vi ikke bare gange tallene. Hvis disse problemstillingene høres kjent ut, har dere kanskje sett https://github.com/anteoas/broch av Anteo AS! Strukturert metode for å beregne på tall med enhet er kjernen av presentasjonen min. Jeg viser også en datanotasjon for tall med enhet, så ingen nye typer og serialisering/deserialisering med pr-str og read-string. Les mer om konferansen og meld deg på (gratis): https://scicloj.github.io/macroexpand-2025/ (Det er OK å kun se på én presentasjon.)
Hjelp meg å nå flere på Linkedin hvis dere vil: https://www.linkedin.com/feed/update/urn:li:activity:7383440917338337280/
Kul!!! Jag ska vara med i en panel på den konferensen. Och: Broch är helt fantastiskt bra!
Gøy! Gleder meg til å se deg der, @pez! Jeg forventer at det blir god tid til spørsmål etter presentasjonen, så still gjerne hvis det er noe du lurer på :=)
Nice! Jeg tenkte umiddelbart på estimering innen programvareutvikling, typ hvor mye tid det tar å gjøre ting eller hva det vil koste. Det er et fantastisk lite kapitell om det i boka "https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/" (kapittel 2.13, sider 64-69). Det kapitellet reddet meg mange ganger når jeg jobbet som teknisk prosjektleder/rådgiver mellom bankkunder og utviklere når vi skulle prise ting. Noe så enkelt som å bruke større units (uker, måneder) istedenfor f.eks. timer, og kommunisere i ranges istedenfor én verdi. Fordi da er usikkerheten bakt inn i estimatet.
Jeg "fikset" hele estimeringsprosessen og verktøyene (stort sett avanserte Excel ark) vi bruke for det i det lille konsulentselskapet 🙂 Selgerne pleide å si ting som "Ah! Dette tar 279.7 timer å implementere" til kundene, LOL. Så ble selvsagt sint hvis det ikke stemte. Når de gikk over til å si "Det vil ta cirka 3~6 uker for én utvikler" så ble ting mye bedre.
En annen grov feil selgerne gjorde var å ikke kommunisere forskjellen mellom "kalendertid" og "effektiv arbeidstid." Så når de sa "Det tar to uker!" så tenkte kunden selvsagt på kalendertid. Og da ble det feil. Fordi utviklerne sjeldent eller aldri har 7,5 effektive timer per dag.
nettopp! Enhet bærer intensjon. "en halv måned" gir mer slingrinsmonn enn 80 timer!
Jepp. Men så må man alltid stille kunden spørsmål som "Hva skal estimatet brukes til?" og "Hvor nøyaktig må det være?"
Fordi noen ganger vil de bare ha et veeeldig grovt estimat for å budsjettere.
Jeg hadde en kunden en gang som svarte "Jeg vil bare vite om det vil koste 6 millioner eller 40 millioner." Mens alle internt satt og krangla om ting som ikke ville utgjøre noe mer enn ~500.000 forskjell i budsjettet.
Begge deler hadde vært OK 😂 Han måtte bare få det inn i en formell budsjettgreie internt.
Morn!
Morn!
Morn!
Morn!
mrn
God morgen
Morn!
mårn
morn