Softwareutvikling

Kjersti Berg (@KjerstiBB) er en dyktig og engasjert utvikler som ikke er redd for å prøve nye ting. For et år siden forlot hun Java til fordel for C#, og for et halvt år siden byttet hun ut konsulentselskapet Miles med PSWinCom, og ble min kollega.

Kjersti står også bak Bergen CodingDojo, og er med og arrangerer BOOSTER-konferansen. I dag følger hun opp en kommentar hun kom med her på bloggen for litt siden…

Hvem er du?
En programmerer med sans for folk.

Hva er jobben din?
Utvikler i PSWinCom i Bergen.

Hva kan du?
Kan slette kode. Ingen kode – ingen bugs.

Hva liker du best med yrket ditt?
At jeg, på en god dag, kan lage noe som kan bidra tilk å gjøre livet litt enklere for noen andre.

Jakten på enhjørningen

tl;dr; Myten om den hyperproduktive utvikleren, er den egentlig sann? Og, bør vi bruke tid på å diskutere den?

Den dukker opp med mer eller mindre jevne mellomrom. Påstanden om at forskjellen i produktivitet blant utviklere er stor. Veldig stor. Større til og med enn blant andre yrkesgrupper. Sist i en artikkkel i Computerworld, der vi kan lese at Lyle M. Spencer rapporterer at de beste systemutviklere produserte 13 ganger så mye testet funksjonalitet per månedsverk som de gjennomsnittlige, og 32 ganger mer enn de dårligste. . Et kjapt søk på “programmer productivity” på Google gir over 12 millioner treff, og mange av dem gjentar denne påstanden i en eller annen form, med litt ulike kilder.

Jeg er i utgangspunktet skeptisk. Jeg får det nemlig ikke til å gå opp med min egen erfaring. Ikke at man skal trekke for bastante konklusjoner bare basert på egne erfaringer, a.k.a. anekdoter, men siden forskjellene er rapportert å være så store, skulle jeg ikke ha sett i det minste noen tegn til dette etter 10 år som utvikler? Flinkere folk enn meg har studert kildene, og utfordret påstandene og kritisert kildebruken. Klart det er forskjell på folk, men er disse forskjellene virkelig den viktigste faktoren for om et prosjekt skal lykkes eller ikke? Bør vi derfor ta konsekvensen av dette og lønne “dyktige” utviklere mer enn de “uproduktive”?

Etter å ha lest litt i noen av kildene som brukes for å underbygge påstanden er jeg ikke blitt mer overbevist. Ingen av de kildene jeg har lest klarer engang å forklare hva produktivitet i vår bransje egentlig er for noe, langt mindre hvordan vi meningsfylt skal kunne måle det. Ingen har klart å finne en objektiv metode for å skille de hyperproduktive fra de mindre produktive utviklerne. Hvorfor ikke? Kanskje fordi hele greien er en myte mer enn faktisk viten? Finnes det ikke egentlig noe som kan kalles utviklerproduktivitet i det hele tatt? Kanskje er produksjon helt feil analogi på det vi gjør?

Men, vil du kanskje si, jeg har nå vitterlig møtt endel idioter i jobben opp gjennom årene. Og noen av dem var ikke bare mindre produktive, de bidro faktisk negativt, fordi vi måtte bruke masse tid på å rydde opp i alt rotet de klarte å produsere. Neste gang du instinktivt tenker det; prøv å se om det finnes andre forklaringer enn bare den enkle; idioten er ikke en så flink og produktiv utvikler som meg. Kan det være at han er blitt tildelt en oppgave han ikke hadde forutsetninger for å løse alene, og fordi det ikke er en kultur for å spørre om hjelp i teamet? Kan det hende han er demotivert, fordi han har sittet med den samme typen oppgaver i flere år, og aldri fått mulighet til å utvikle seg? Har han kranglet med sjefen? Har han kranglet med kona?

I en studie om kollektiv intelligens, ble 192 team ble satt sammen på ulikt vis og gitt et sett oppgaver de skulle løse for å finne ut hvilke faktorer som påvirket gruppens score. Team med gruppemedlemmer med høy IQ gjorde det ikke bedre enn team der medlemmene hadde lavere IQ. Faktisk var heller ikke faktorer som motivasjon, samhold eller tilfredshet i gruppen avgjørende. Det som sto igjen som den viktigste faktoren var andel kvinner i gruppen! Som kvinne er det selvfølgelig deilig å kunne slå en mannlig kollega i hodet med slike resultater, men, som forskerne selv sier; poenget er nok ikke først og fremst å ha med mange kvinner, men å ha med folk som er flinke til å lytte til hverandre, som er sensitive til andres behov, som er åpne til andres idéer, egenskaper som de altså mener er mer fremtredende hos kvinner enn hos menn.

Hvis jeg har vært flink (sic!) nå, så er du kanskje overbevist om at utviklerproduktivitet ikke er et så veldig interessant fenomen å snakke om. Men, er det så farlig å gjøre det? Det er jo ikke på noen måte bevist at det ikke er så store forskjeller blant utvikleres evne til å løse problemer, selv om vi ikke klarer å måle det ordentlig ennå. Det føles jo ofte intuitivt riktig, selv om ikke forskningen gir ryggdekning for det. I tillegg er det jo deilig å føle seg som en del av en produktiv elite, ikke sant?

Jeg tror det gjør noe. Hva tenker du for eksempel om kollegaene dine? De som aldri drar på konferanser, og som ikke lærer seg et nytt programmeringsspråk hvert år. Eller han nye kisen som kommer rett fra skolen, og ennå ikke har lært seg hva som er «best» av TDD og BDD, eller ikke har sterke meninger om distribuert versjonskontroll og DI-rammeverk. Er du i stand til likevel å lære noe av ham? Lytter du ordentlig til det han sier, eller avviser du ham som en dinosaur eller noob, alt ettersom? Å lage software er helt grunnleggende en sosial aktivitet, men, når vi er for opptatt av å dyrke de beste, å forsøke å bli en av de beste, de hyperproduktive, geniale utviklerne, så er det lett å glemme det.

Med andre ord; jeg tror påstanden, eller egentlig, myten om den geniale utvikleren, ødelegger for vår evne til å vise respekt, høre på andre,og være ydmyk om egne evner. Jeg tror den gjør oss til større rævhol enn vi trenger å være. Og hvem vil vel egentlig være det?

Hvis du skal ansette noen utviklere, så for all del; gjør ditt beste i å finne noen som du tror er flinke og engsjerte, men enda viktigere; finn noen som du tror vil passe inn i organisasjonen din. Og, viktigst av alt, tør å analysere hvordan organisasjonen din hjelper eller hindrer de utviklerne som er der i å gjøre en så god jobb som de kan. Det er mye mer å hente der.

The talent myth assumes that people make organizations smart. More often than not, it’s the other way around. (Malcolm Gladwell, The talent myth, fra the New Yorker)

Denne bloggen føles ikke komplett uten en post om hva programmering er for noe.

Å programmere er å instruere en eller flere datamaskiner til å gjøre noe. Å programmere er å lage en oppskrift som datamaskinen kan følge, og som vil resultere i noe som forhåpentligvis er nyttig for noen.

Det høres jo ganske greit ut.

Men tenk litt over det…

En datamaskin kan skape en illusjon om at den inneholder fotografier, tekstdokumenter, musikk og filmer. Det eneste den egentlig inneholder derimot er bits…, det vi ofte representert som 0 og 1. Mange bits! Strukturert i mønstre det er umulig for menneskehjernen å gjenkjenne. Datamaskinen din er laget for å lagre bits, og alle filene og mappene og data av ulik art er illusjoner skapt av programmerere.

Dijkstra, en av programmeringens store helter, har beskrevet programmering som den største intellektuelle utfordringen i menneskenes historie – uten sidestykke.

Hva er det som gjør programmering så utfordrende? Dijkstra svarer selv på dette ved å påpeke at en kompetent programmerer er fullstendig klar over den begrensede størrelsen på sin egen hjerne (Kilde: The Humble Programmer, 1972). Å få en haug med 0′ere og 1′ere til å bli noe fornuftig er utrolig komplisert, og vår oppgave som programmerere er å administrere denne kompleksiteten.

“Controlling complexity is the essence of computer programming.”

Brian Kernigan

Datamaskinen gjør akkurat det du forteller den at den skal gjøre. Hverken mer eller mindre. Alle feil et program gjør er i utgangspunktet resultatet av en menneskelig feil.

“That’s the thing about people who think they hate computers.  What they really hate is lousy programmers.”

Larry Niven

Men samtidig som utviklere lager en “oppskrift” for datamaskinen så lager han ofte også noe som skal spille sammen med mennesker. Og de er ikke like rasjonelle og forutsigbare. Dette gjør programmering ekstra vanskelig – man må forstå både hvordan mennesker og datamaskiner fungerer, og det er to veldig forskjellige ting.

For å gjøre programmeringen enklere bygger utvikleren abstraksjoner – lag som skjuler kompleksitet. Vi gjenbruker ting som andre har gjort, og fjerner oss mer og mer fra hvordan maskinen egentlig fungerer. Men abstraksjonene er sjelden perfekte, og manglende forståelse fører til enda flere utfordringer for den stakkars programmereren.

“Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.”

Alan Kay

Programmerere jobber altså med datamaskiner og mennesker på forskjellige nivåer – noen kjenner veldig godt hvordan maskinen fungerer, skriver såkalt assembly-kode, og kaller seg hackere. Andre forholder seg til design av større systemer, og kaller seg gjerne arkitekter. Noen lager bare grensesnitt som mennesker kan bruke til å kommunisere med datamaskinen, og kaller seg kanskje til og med bare for designere.

Og vanskelighetsgraden kan variere veldig.

Det sies også at programmerere varierer veldig i forhold til hvor dyktige de er. Kanskje mer enn innenfor noe annet felt..

“A hacker on a roll may be able to produce–in a period of a few months–something that a small development group (say, 7-8 people) would have a hard time getting together over a year.  IBM used to report that certain programmers might be as much as 100 times as productive as other workers, or more.”

Peter Seebach

“..a great writer of software code is worth 10,000 times the price of an average software writer.”

Bill Gates

Man trenger ingen utdanning for å kunne kalle seg programmerer, og det finnes mange som har lært seg alt de kan på egenhånd, uten at det virker som noe problem. Men samtidig sies det at det å mestre programmering kan ta 30 år med kontinuerlig læring. Dessuten er det lite enighet rundt om programmering er en vitenskap, et ingeniørfag, et håndtverk, eller en kunstform. For eksempel sier man at en informatikk-utdanning (Computer Science) ikke kan gjøre deg til en programmeringsekspert, på samme måte som at det å studere pensler og pigmenter ikke kan gjøre noen til en stor maler.

Forfatteren av boken The Developers Code illustrerer hvor mange fasetter programmeringsyrket har i sin definisjon av hva en moderne programmerer er:

I am a nonaccredited, overly logical psychologist, therapist, mechanic, diplomat, businessman, and teacher working in an inductry that is still defining itself each and every day.

Programmering er et merkelig yrke. Det finnes mange, motstridende meninger om hvordan det skal gjøres. Det kan være utrolig krevende, men likevel utrolig gøy og motiverende. Man kan bygge ting av ingenting – som trollmenn kan vi skape noe i hjernen vår, skrive noen “trylleformler”, og vips så bringer datamaskinen det til live.

Jeg er stolt over å være en programmerer. Samtidig føler jeg meg veldig priviligert. Tenk at noen vil betale meg for å forsøke å gjøre det mest utfordrende og kompliserte vi mennesker kan foreta oss.

I forrige uke holdt jeg et foredrag på det tekniske sporet av Digitalkonferansen 2012. Her poster jeg slidene mine og alle notatene, slik at du også kan få med deg budskapet, selv om du ikke var på sørlandet denne fine septemberdagen.

Jeg fikk mange positive tilbakemeldinger på presentasjonen. Flere kommenterte at de likte det behagelige tempoet mitt, og de eldre blant publikum satte pris på at jeg påpekte at også de hadde noe å komme med for den moderne utvikleren.

Først introduserte jeg meg selv, firmaet (PSWinCom), og min rolle der. Men jeg hadde 30 slides å komme gjennom på 30 minutter, så jeg gikk raskt igang med selve foredraget… Her følger “lysbilder” og notatene:

Jeg gav foredraget mitt en såpass generell tittel fordi det betyr at jeg egentlig kan snakke om hva som helst. Bedre å be om tilgivelse enn tillatelse! Jeg lover derimot at det er en rød tråd i det jeg sier, selv om det ikke nødvendigvis kan virke sånn hele tiden.

Jeg har et spørsmål til dere: Har du noen gang følt deg dum?

Har du noen gang følt deg utilstrekkelig som utvikler?

Å være utvikler i dag betyr å bli bombadert med nye ting hele tiden – nye rammeverk, nye verktøy, nye programmeringsspråk, nye begreper, nye plattformer å utvikle for – ting man som en moderne utvikler i 2012 bør vite noe om for å ikke virke dum. Det kan være ganske overveldende, og det er lett å bli stressa.

Det jeg vil forsøke her i dag er å hjelpe deg å se en vei gjennom dette, en vei som ikke fører til stress, en vei som lar deg bli en dyktig utvikler som leverer gode løsninger uten å bli utbrent etter noen få år. Jeg håper dere er interessert i det.

Jeg skal begynne med å introdusere dere for en rekke personer…

La oss begynne her med en person dere alle kjenner. Steve Jobs. Grunnleggeren av Apple. Hyllet over hele verden for sine prestasjoner. Mobil er et sentralt tema her i dag, og det skyldes mye at Steve Jobs lanserte iPhone sommeren 2007, og AppStore sommeren 2008. Dette skapte et helt nytt marked, en ny plattform hvor vi utviklere kunne levere brukere det de vil ha.

Men jeg skal ikke si så mye mer om Jobs, bortsett fra at han døde 5. oktober i fjor.

Vet dere hvem dette er?

Dette er John McCarty. McCarty er personen som oppfant programmeringsspråket LISP. Han gjorde dette så tidlig som i 1958. Det finnes flere varianter av LISP som fortsatt brukes i dag, og språket anses fortsatt som det kraftigste språket vi har til å uttrykke oss som programmerere. Nær sagt ALLE programmeringsspråk som er laget siden har lånt elementer fra LISP. LISP var det første språket som hadde den typiske if/else-konstruksjonen. Og LISP var for eksempel også det første språket hvor man hadde garbage collection.

John McCarty er også grunnleggeren av fagfeltet kunstig intelligens. Alle som er interessert i kunstig intelligens burde se opp til McCarty som sitt store forbilde.

John McCarty døde også i oktober i fjor. Det er ikke like mange som har hørt om det dødfallet.

Vet dere hvem dette er da?

Dette er Dennis Ritchie. Dennis er først og fremst kjent for å ha utviklet programmeringsspråket C. Hvis noen har påvirket hvordan vi programmerer i dag like mye som John McCarty har gjort, så må det være Dennis Ritchi.

Hvis dere ikke har skjønt det enda så er jeg altså veldig opptatt av programmeringsspråk :)

Og tro det eller ei, men Dennis døde OGSÅ i oktober i fjor. Det er ikke så mange som har hørt om det heller…

Er det ikke ganske historieløst at media eller bransjen fikk med seg dette?

Dennis hadde en kollega og god venn som heter Ken Thompson. Sammen utviklet de UNIX. C ble utviklet fordi de trengte et programmeringsspråk til UNIX. Og C var basert på programmeringsspråket B, som var laget av Ken Thompson. Ken er også mannen bak UTF8-encodingen og mye annet rart. Det er smarte folk dette her altså.

Og bare så det er sagt – Ken døde IKKE i oktober i fjor! Han lever i beste velgående, jobber for Google, og har blant annet hatt en finger med i utviklingen av programmeringsspråket Go som Google har utviklet.

Grunnen til at jeg nevner Thompson er noe han sa til sønnen sin da han skulle velge karriærevei. Ken sa til sin sønn at han IKKE måtte bli programmerer! Det var etter Ken’s mening ikke noen vits i å bli programmerer nå fordi det ikke har skjedd noe nytt og uforutsigbart innen programmering de siste 20-30 årene.., hvis man ser bort fra at vi fikk internett da.

Den dyktige utvikleren som står bak UNIX, og som fortsatt henger med og jobber for et av verdens mest spennende selskaper mener altså at det ikke gjøres noe nytt og spennende i denne bransjen. Hvordan passer dette sammen med hva jeg sa innledningsvis?

Dette bør dere vite hvem er. Han er norsk, og han lever også fortsatt.

Dette er Trygve Reenskaug, norges mest kjente, nålevende utvikler. Dere har hørt om MVC – Model-View-Controller? Det har jo blitt veldig populært å si at du bruker MVC-pattern de siste årene. Trygve var den som kom opp med dette patternet på 70-tallet, da han var på Xerox PARC i Palo Alto og jobbet med SmallTalk.

Var du så heldig å få høre Trygves foredrag på Norwegian Developers Conference i fjor, så hørte du ham si noe sånt som at det ikke har skjedd noen som helst utvikling i forhold til hvordan vi utvikler software, siden 60-/70-tallet. Han viste stor frustrasjon og var nesten litt sint over hvor lite vi har utviklet oss.

La meg introdusere én gamling til…

Dette vet sikkert mange hvem er: Robert C. Martin, også kjent som Uncle Bob. Personen som trommet sammen møtet som gav oss det smidige manifestet. En ledende skikkelse innen Software Craftsmanship bevegelsen.

Uncle Bob er en inspirerende foreleser, og har vært mye i Oslo. I et av foredragene sine sier han at hvis du hadde en tidsmaskin, hentet en utvikler fra 60-tallet og tok han med hit, så ville han (etter å ha kommet over kultursjokket) ganske lett kunne begynt å programmere med de verktøyene vi har i dag… Programmering har i bunn og grunn ikke endret seg fra den gang og til i dag.

Ja, vi har funnet på mange nye måter å strukturere og pakke inn programmene våre på, men i bunn og grunn er programmering ikke noe annet enn iterering, assignment (tilordning) og ta avgjørelser (if/else).

JavaScript er veldig HOT for tiden – noe alle snakker om. Node.js gir oss JavaScript på serveren, og det er det bare de kuleste av de kule som driver med.

Men JavaScript er selvfølgelig ikke noe nytt – det ble utviklet i 1995 – det er 17 år siden det.

Og JavaScript på server-siden har vi hatt like lenge – er det ingen som har hørt om Netscape Enterprise Server, lansert omtrent samtidig med JavaScript?

Erlang er et annet språk – og en plattform – som har blitt lagt merke til de siste årene, fordi det er så bra egnet til å lage robuste, distribuerte systemer.

Men Erlang er ikke noe nytt! Erlang ble utviklet på 80-tallet!

Funksjonell Programmering da? Det er hot det! Det har dukket opp mange, nye språk for dette, og det er vel det siste nye? Jeg tenker på språk som Scala, F#, Clojure osv.

Men funksjonall programmering er mye eldre enn f.eks. objektorientert programmering. Funksjonell programmering var hot på 60-tallet det. Faktisk kan vi gå helt tilbake til LISP på slutten av 50-tallet for å finne røttene til funksjonell programmering.

Så funksjonell programmering er i alle fall ikke noe nytt.

(Har la jeg også inn en kommentar til et foredrag som Morgan Simonsen fra Atea holdt tidligere på dagen, hvor han fortalte at Cloud-teknologien – hvordan vi snakker om og bruker nettskyen i dag – første gang ble beskrevet (og beskrevet ganske nøyaktig, bare med et annet navn) i en bok publisert i 1966. Nettskyen er ikke noe nytt!)

Softwareutvikling har altså – i alle fall i følge en rekke, gamle utviklere – ikke utviklet seg særlig mye de siste 20 – 30 – 40 – kanskje 50 årene. Det er den blå kurven. Vi gjør ting i større skala, og med større komersiell suksess, men i bunn og grunn gjør vi det samme som folk har gjort før oss.

Hva er det som har utviklet seg da? Hardware! Hardwaren vi bruker, den har utviklet seg. Teknologien som ligger i bunn. Hvordan datamaskinen har infiltrert stadig nye områder, og blir viktigere og viktigere i vår hverdag.

iPhone ble som sagt lansert i 2007, og i 2008 kom AppStore. I 2010 hadde Apple hatt 25 milliarder nedlastinger fra AppStore. Bruken av Smartphones har nå nådd en kritisk masse.

Jeg har funet frem et par grafer som viser litt om veksten i Norge:

(Jeg sa nok noe her også, men ikke noe annet enn hva du kan se ut av grafen.)

(Og her sa jeg noe om at vi ser en stor trafikkvekst fra mobil og tablets, mens trafikken fra desktop holder seg stabil.)

Da jeg begynte i softwarebarnsjen jobbet jeg med litt av hvert. Etter en stund ble det mer og mer utvikling for web, og jeg benynte å kalle meg en webutvikler. I dag er det nesten ingen som kaller seg for webutviklere – man er bare UTVIKLERE. Nesten alt har med internett å gjøre i dag. Webutvikling er implisit.

Jeg tror vi snart er der når det gjelder mobil også. I dag er det mange som sier de er mobilutviklere – de er spesialister på utvikling for mobile plattformer. Men jeg tror vi er der nå hvor omtrent alle utviklere må ta inn over seg at vi alle må være mobilutviklere, slik vi alle er webutviklere.

Vi kan ikke lenger fokusere på bare webbruk fra desktop – vi har mobil også. Folk forvente å kunne få tilgang til informasjonen sin på mobilen, og vi må tilpasse oss!

Men det vil være feil å fokusere bare på desktop og mobil – vi har tablets også! Tablets har andre bruksmønstre enn både desktop og mobil, og de begynner og bli ganske utbredte de også.

Men, det vil være feil å fokusere på bare desktop, mobil og tablets – nå kommer smartTV’ene for fullt!

Og det kommer ikke til å stoppe der…

Dette er en fyr som går med Google Glass. (Fortalte litt om hva dette kommer til å være, og hvilke fordeler det gir. Senere på dagen fortalte ex-IT-direktøren fra Norwegian at de hadde vurdert å satse på Google Glass til sine serviceteknikere.)

Glass vil sannsynligvis være tilgjengelig allerede fra neste år av.

Eller hva med dette?

Dette er et headset som heter EPOC. Dette har vært tilgjengelig på markedet i noen år nå, og lar deg kontrollere datamaskinen vha. tanker og følelser. Det er vistnok ikke enkelt å bruke, men dette kommer til å bli bedre med årene.

Utviklingen av nye bruksområder for teknologi går bare raskere og raskere. Om vi alle kommer til å gå runndt med VR-briller og styre computeren vår med tankene om fem år, det vet jeg ikke. Men at utviklingen kommer til å fortsette er jeg overbevist om!

Det vi opplever er at brukeren ikke bare ønsker, men krever tilgang til informasjonen sin og funksjonene sine, samme hvor han befinner seg.

I en keynote i 1990 presanterte Bill Gates slagordet sitt – “Information at your fingertips” – og beskrev et samfunn hvor man alltid hadde tilgang til informasjon. Han beskrev verden slik den er i dag!

På NDC i år ble jeg introdusert for begrepet “device-first computing”. Det dreier seg om å lage løsninger tilpasset det kunden vil ha nå – i 2012.

Bla, bla, bla…. (sa noe mellom linjene her også, men hva?!)

Jeg sa jeg ville hjelpe dere å takle den enorme strømmen av ny informasjon, nye produkter og teknologier, og hjelpe dere å se hverden på en ny måte. Her kommer noen konklusjoner..

Første konklusjon kommer i form av et sitat fra en pioner innen programmering som heter David Parnas….

Altså: de fundamentale ideene er viktigst, ikke den siste, nye teknologien. Ikke kast alt det gamle på båten hver gang Apple eller Google eller Microsoft kommer med noe nytt.

Bransjen vår er ikke historieløs, men mange utviklere er det. Hvis vi skal komme noen vei må vi slutte å finne opp hjulet på nytt og på nytt.

For å få til å gi brukeren riktig opplevelse tilpasset riktig kontekst (med de ressursene et normal IT-selskap eller IT-prosjekt har i Norge) må vi ikke henge oss for mye opp i detaljene eller hver enkelt device.

Jeg vil avslutte med et sitat fra nok en eldre herremann – oppfinneren av programmeringsspråket Smalltalk. Og den egentlige oppfinneren av iPad en gang på 70-tallet.., ikke at Apple noen gang kommer til innrømme det…

Ikke kast deg på alt det nye som alle andre kommer med. Utdann deg, gå til kilden, lær av historien, og du vil være bedre rustet til å møte dagens og morgendagens utfordringer!

Jeg har lekt meg litt med noen forsøk på å visuelt illustrere noen typiske software-arkitekturer. Er det noen av disse du kjenner deg igjen i? Jeg begynner med den aller mest gjenkjennelige arkitekturen av dem alle:

De fleste vet at Big Ball of Mud ikke er særlig bra. For å fikse problemet lærer man at man bør splitte arkitekturen sin opp i lag. Tre lag skal være bra har jeg hørt. Men det kan være lett å missforstå hva det egentlig betyr. Her har dere den vanligste oppdelingen for webprosjekter:

Hvis tre lag er bra må jo fem, eller kanskje åtte, være enda bedre:

Den typiske, lagdelte arkitekturen – en stabel med mudballs som balanserer på toppen av en database. Nice! Men hva skjer når vi har behov for flere systemer som må kommunisere sammen? Jo, da trenger vi et integrasjonspunkt:

Databasen utgjør jo et fint API, ikke sant? Ikke det? Ok, hva med denne da:

Her har vi flyttet integrasjonspunktet ut, og gjenbruker lagene der vi kan. Dette minner faktisk om ganske mange av systemene jeg har vært med å jobbe på. Ser du at det nesten ser ut som en kaktus? Ofte føles det sånn ut også…

Nå har vi blitt moderne; med Service Oriented Architecture har vi byttet ut den enorme databasen med mindre tjenester som har mindre ansvarsområder og tar vare på sine egne data. Det ser ganske løsrevet og fint ut, men komponentene henger fortsatt for tett på hverandre. For å løse dette introduserer vi en ny, swær mudball:

Tjenestene er nå løsrevet fra hverandre, men vi har fått et dyrt monsternav i midten med høy kompleksitet. Utviklere må sitte time etter time for å konfigurere informasjonsstrømmer.

Wild messaging er state of the art SOA. En generisk meldingsbuss sørger for at tjenester kan snappe opp hendelser de er interesserte i.

En meldings-pipeline er én ting man kan få ut av SOA 2.0, og er en typisk arkitektur man kan benytte seg av for å begrense størrelsen på hver enkelt mudball. Tjenestene vet ideelt sett ikke om hverandre, men i praksis flyter meldingene i en fast strøm mellom dem.

I et P2P-nettverk har man droppet det sentrale navet, og tjenestene må selv sørge for at alle meldinger distribueres der de skal. Det finnes et hav av varianter her…

Til slutt tar jeg med CQRS-arkitekturen, nok en måte å redusere størrelsen på mudballs ved at man skiller behoved på å lese data fra behovet for å gjøre endringer. Denne modellen kan benyttes i hver av tjenestene i de øvrige arkitekturene.

Og det var det – 11 illustrasjoner av hvordan vi utviklere setter sammen baller av kompleksitet.

Jeg er en sånn programmerer som bruker mye magefølelse og intuisjon. Kode skal se bra ut, den skal føles riktig.

For noen dager siden hadde Computerworld en artikkel hvor de skrev om Vakker programvarekode. De fortalte at det er svært vanlig å vurdere hvor vakker kode er, og at de mest erfarne utviklerne er de mest estetikk-orienterte. Artikkelen snakket om studier som viser at vi vurderer estetiske kvaliteter i kode før vi vurderer korrekthet, og at mye tyder på at identifikasjon av stygg kode brukes som indikator på problematisk kode.

Men artikkelen skraper bare i overflaten av hvorfor estetikk er viktig – hvorfor eksperter dømmer kode ut i fra hvor vakker den er. For skal ikke kode bare gjøre jobben sin.., spiller det noen rolle hvordan den ser ut? Datamaskinen bryr seg jo ikke. I går kom jeg til eksempel over en blogpost som hardnakket hevder:

“Your job is to solve a business problem, not to create a thing of beauty. Your ideals—what you feel is attractive, innovative, or effective—are secondary to what your client needs.”

Det er flere grunner til at vakker kode er viktig. Men det jeg synes er mest interessant er hva “vakkert” er for noe. Siden vi mennesker gjennom evolusjonen har utviklet denne egenskapen – å synes at noe er fint – så må det jo nesten ha en funksjon.

Og dette vet vi faktisk en god del om. Når du synes noe er vakkert så kan du se på det som at intuisjonen din forsøker å fortelle deg at det du ser er bra. Noe som er “riktig”, noe som vil fungere godt. Studier har gang på gang vist at vakre utgaver av fremkomstmidler, redskaper o.l. er bedre enn de mindre vakre utgavene (se linker nederst). Tiltalende websider er enklere å bruke enn stygge websider. Dette er ikke fordi vakkerhet gjør ting bedre, men fordi vi synes at velfungerende ting er vakre!

Hjernen vår har to moduser som fungerer side ved side. L-modusen (det vi tradisjonelt har kalt venstre hjernehalvdel) er sekvensiell og analytisk. Det er den vi resonerer med, det er den som er vår indre monolog. R-modusen derimot (trad: høyre) kan du se på som en prossess av veldig mange parallelle tråder. Den er utrolig flink til å søke i hukommelsen vår og finne mønstre blant alle våre erfaringer, og gjennom det løse problemer.

Men R-modusen har ikke noe språk – den bruker ikke ord – og for at vi skal bli bevisste på hva R-modusen kommer opp med må det kommuniseres gjennom andre kanaler. Bilder. Følelser. Intuisjon. Estetikk!

Dyktige utviklere (og dyktige utøvere innen de fleste andre felt) lærer seg å bruke R-modusen som en viktig ressurs for å løse problemer. Gjennom erfaring har de opparbeidet seg det man kaller en intuitiv forståelse. I foredraget Hammock-driven Development forklarte Rich Hickey i 2010 hvordan han laster opp hjernen sin med så mye informasjon som mulig om et problem, for så å slappe av (i hengekøyen) og bevisst la være å tenke på problemet. Å “la være å tenke” vil si å roe ned L-modusen, slik at R-modusen får jobbe i fred. Da kommer løsningene raskere, helt “av seg selv”.

Andre kjente teknikker for å aktivere R-modusen er å gå seg en tur, spille foosball på pauserommet, eller på andre måter aktivere kroppen og distrahere den indre monologen. Å sitte stille forran PC-skjermen er ikke den beste måten å løse komplekse problemer på.

Så skjønnhet er viktig! Når du synes kode er vakker er det kanskje hjernen din som bruker en snarvei til å fortelle deg at den er bra.

Men du skal vær bare klar over at R-modusen ikke er feilfri. Vi har alle våre bugs, og intuisjonen vår tar ofte feil. Kjente forelesere i software craftsmanship-bevegelsen som for eksempel Dan North snakker om såkalte cognitive biases (vurderings-skjevhet). R-modus kan brukes til å komme opp med løsningsforslag eller forslag til sannheter, men så bør man analysere (bruke L-modus, bevisst logikk) for å verifisere. I Pragmatic Thinking & Learning (som jeg på det sterkeste vil anbefale) sier Andy Hunt:

“Lead with R-mode; follow with L-mode.”

I den moderne, vitenskapsbaserte verden – og kanskje spesielt i Vesten – er vi veldig fokusert på L-modusen. Det er den vi aktiviserer på skolen, og vi lærer svært lite om hvordan vi kan utvikle intuisjonen vår. Men skal man bli virkelig dyktig er det ingen vei utenom om tappe potensialet som ligger “i høyresiden”.

Vakker kode er ikke bedre i seg selv. Men utviklere synes at kode som kommuniserer godt, er fleksibel og har lav kompleksitet, er vakrere enn annen kode. Og dette kan man bruke som en snarvei; men kan skrive kode man synes er fin, mens det som egentlig skjer er at underbevisstheten hjelper deg og passer på at du gjør ting så godt som mulig, basert på dine tidligere erfaringer.

Så forsøk å gjøre koden din vakker – for det er en grunn til at du har en estetisk sans.

Vakker kode er som regel bedre!

Referanser:
* Emotional Design: Why We Love (or Hate) Everyday Things
* Apparent Usability vs. Inherent Usability
* Aesthetics and Apparent Usability
* A Neuropsychological Theory of Positive Affect and Its Influence on Cognition
* Automatic Effects of Brand Exposure on Motivated Behavior: How Apple Makes You “Think Different”

Det kan være vanskelig å skaffe seg den komplette oversikten over agendaen for Norwegian Developers Conference 2012 – det er jo så mange tema og navn å holde orden på. Jeg gjør mitt beste for å vise vei i mylderet av presentasjoner, og har nå kommet til det andre av konferansens hovedtema…

NDC er en smidig konferanse, og tiltrekker seg noen store navn på dette feltet. Her har jeg valgt ut de mest spennende foredragene og foredragsholderne.

Smidige teams og prosjekter

Dan North er en fyr du absolutt ikke bør gå glipp av. I foredraget Embracing Uncertainty vil han snakke om kjernen i smidig utvikling. Dette kommer til å bli et av høydepunktene om du spør meg.

Jonathan Rasmusson, forfatteren av boken The Agile Samurai, er også en veldig spennende foreleser. Han vil holde to foredrag om smidig ledelse under konferansen.

Konferansedeltagere som vil lære mer om Scrum får også muligheten til å tilbringe en hel dag med Mike Cohn. I år vil han blant annet fokusere på ting som estimering, planlegging, user stories, og hvordan man skalerer scrum til distribuerte team.

I tillegg vil jeg nevne at Cory Foy vil snakke om Kanban, og at Paul Goddard og Geoff Watts vil holde en tre timers lang workshop de har valgt å kalle Game Oriented Agile Learning.

Bli en bedre utvikler

Craftsmanship handler om hvordan vi enkeltvis utøver faget vårt, og hvordan vi blir bedre utviklere. Robert C. Martin‘s sesjoner representerer som regel høydepunktene for meg på konferanser som dette, og i Professional Software Development vil han snakke om hva det vil si å være en profesjonell utvikler i 2012.

I følge ryktene er Venkat Subramaniam en utrolig dyktig og populær foreleser. Han vil blant annet snakke om betydningen av kodekvalitet. Roy Osherove er også med, og vil i år fortelle deg hvordan du kan bli en bedre utvikler ved å bryte ut av din komfort-sone.

Og så er du nesten nødt til å få med deg Greg Young. Jeg vurderer faktisk å delta på hans pre-conference workshop også. Under konferansen vil han snakke om hvordan man raskest mulig kommer igang med å levere reell verdi på et nytt prosjekt.

Når utviklerne tar kontrollen

NDC 2012 vil også gi deg et par foredrag som snakker om hva som skjer når utviklerne kaster bort alle formaliteter og tar styringen selv. I Programmer Anarchy vil Fred George fortelle om steget etter Agile, og morromannen Zach Holman vil gi oss et innblikk i hvordan ting fungerer internt hos GitHub.

Det blir også flere DevOps-relaterte sesjoner. David Farley er en av forfatterne bak boken Continuous Deliver, som ble kåret til den aller viktigste og beste boken for utviklere i fjor. Han kommer til NDC for å snakke om dette.

Noen andre potensielle høydepunkt

En sesjon jeg er litt spent på er Hadi Hariri‘s Developers: The Prima Donnas of the 21st Century. Det høres ut som om han vil provosere litt, og det kan jo bli gøy. Ellers vil jeg nok ta turen innom You had me at Halo, et foredrag om hva vi kan lære av online gaming for å skape bedre kommunikasjon og samarbeid i distribuerte utviklerteam.

Som du ser er det nok av sesjoner som vil fortelle deg hvordan du både som individuell utvikler og som teammedlem bør forholde deg til softwareutvikling. Dette er presentasjoner som vil gi både nyttige tips og inspirasjon til å bli bedre utviklere, og jeg gleder meg sykt mye til noen av disse.

Tidligere poster om de røde trådene: Webutvikling på NDC 2012.

Jeg følte bloggen min manglet en post som dette. Med fare for at jeg egentlig er 10 år for sent ute så har jeg likevel lyst til å dele noen tanker om smidig utvikling – sette foten ned og si hvor jeg står!

Det er mange som har forsøkt å definere hva smidig utvikling er for noe. Vi har jo det smidige manifestet, og vi kan si at smidig utvikling er å følge det. Eller man kan si at smidig er å bruke Scrum, å bruke Kanban, eller å følge eXtreme Programming.

Og WikiPedia sier: “Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.”

For meg er smidig egentlig ganske enkelt. Det er å innse og deretter ta følgende av disse tre sannhetene:

• Du vil aldri klare å samle alle krav til en løsning før du begynner!
   
• Kravene vil garantert komme til å endre seg underveis!
   
• Det vil alltid være mer å gjøre enn man har tid til!

Når man innser betydningen av disse påstandene følger resten naturlig av seg selv:

• Man må utvikle noe som fungerer så raskt som mulig, sånn at man kan se det, vise det til andre, og gjennom det oppdage veien videre.
   
• Man må ikke få panikk når veien endrer seg – det spiller liten rolle hva man tenkte for en uke siden hvis det ikke er det man trenger i dag.
   
• Man må utvikle systemer på en måte som gjør at de kan endres – for eksempel ved å bruke testdrevet utvikling, og vet at alle er med og tar ansvar.
   
• Man må sørge for at teamet har nok, delt kunnskap om løsningen og hvordan veien endrer seg, siden man ikke kan ha en ferdig plan å jobbe ut fra. Dette krever tett og hyppig kommunikasjon. Parprogrammering hjelper veldig.
   
• Og man må prioritere hardt og gjøre det viktigste først, samtidig som man alltid har noe som er testet og fungerer – sånn at arbeidet ikke er bortkastet når tiden og pengene tar slutt.

Å jobbe smidig er mere krevende enn tradisjonell fossefallsutvikling. En smidig utvikler må beherske flere egenskaper enn programmering, han må i stor grad overta oppgavene til alle rollene som normalt sett kom både før og etter selve utviklingssteget. Dine oppgaver som en smidig utvikler er:

• Kravanalyse og kundekontakt: Å hele tiden jobbe med å forsøke å forstå behovet til “kunden”
   
• Prosjektplanlegging: Å hele tiden tenke smart i forhold til hva neste steg optimalt sett bør være
   
• Design og Arkitektur: Å hele tiden tenke på hvordan løsningen bør designes for å være mest mulig fleksibel
   
• Prosjektstyring: Å hele tiden kommunisere med alle andre team-medlemmer om endringene som skjer
   
• Implementasjon: Å hele tiden tilføre verdi gjennom å kode løsningen med så høy kvalitet som mulig
   
• Quality Assurance: Å hele tiden tenke kritisk og teste løsningen så effektivt som mulig

I tillegg flyter den smidige utvikleren også ofte over i en driftsrolle, fordi man ofte vil rulle ut løsningen hyppigere for å utnytte verdien som allerede finnes i systemet. En smidig utvikler er altså en generalist og en multi-tasker, med en mye mere interessant hverdag enn den tradisjonelle utvikleren.

Og med mye mere stress om man ikke fullt og helt aksepterer hva smidig egentlig betyr!

Det var alt jeg hadde å si om den saken. Les også Forvirring rundt smidig utvikling eller Utviklerprofiler og fire ferdighetskategorier.

Følgende, lille historie oppstod spontant da jeg på et forum i dag for fjortende gang forsøkte å svare på spørsmålet “hvor lang tid tar det å lære programmering?”.

Jonas og Diana står overfor et problem. De bruker begge programmering til å løse problemet. De hadde ikke løst akkurat denne utfordringen før, og måtte lære seg noen nye teknikker for å få det til.

Et halvt år senere står de begge overfor et nesten identisk problem. Jonas repeterer det han gjorde første gangen, og ender opp med omtrent den samme løsningen. Diana gjenkjenner at hun har gjort dette før, husker hvilke svakheter løsningen hun da lagde hadde, og bruker erfaringen til å lage en bedre løsning denne gangen.

Tre måneder til går, og omtrent samme utfordring dukker opp igjen. Jonas gjør som han pleier – det er kjedelig, men det funker. Diana bruker erfaringen sin fra nå å ha gjort dette to ganger på to ulike måter til å lage et generelt rammeverk som kan brukes til å løse alle lignende oppgaver.

Enda litt tid går, og det dukker opp et problem som ligner på de forrige, men som skiller seg ut på noen sentrale områder. Jonas er nå ganske demotivert, og står i tillegg litt fast fordi han ikke skjønner hvordan han skal løse et par av problemene som er veldig forskjellige fra det han har gjort tildigere. Diana bruker rammeverket sitt, men må endre det på enkelte områder for den nye oppgaven. Hun slipper å bruke tid på de grunnleggende greiene, og lager i stedet et nytt program som modifiserer rammeverket sitt – hun gjør rammeverket programmerbart. Nå kan det brukes til å løse et helt hav av utfordringer.

Dianas arbeidsgiver ser at det hun har laget er så bra at det kan selges som et eget produkt, og gir henne en kraftig bonus.

Jonas blir utbrendt, og begynner på Mac’ern.

Det Jonas driver med kan knapt nok kalles programmering. Han lærer ikke, han løser ikke nye problemer, og kommer ingen vei. Diana, derimot, gjør hele tiden noe nytt, lærer og forbedrer både sine teknikker og resultatet. Det er det hun holder på med som gjør programmering så kraftig og så fantastisk. Det Jonas gjør burde ikke være lov!

Så ikke gjør ting som en datamaskin kunne gjort bedre enn deg. Og ikke tenk at du noen gang skal bli utlært og kunne alt. Med den innstillingen vil du ende opp med å kunne svært lite!

Andy Hunt er en av de 17 utviklerne som var med og laget The Agile Manifesto. Dave Thomas er Ruby-utvikleren som er kjent for å ha kommet opp med konseptet Code Kata. I 1999 gikk disse to sammen og skrev boken The Pragmatic Programmer: From Journeyman to Master.

I dag er dette den boken som oftest anbefales til nye softwareutviklere, og i mange firmaer er det til og med fast praksis å dele den ut til nye ansatte. Den inneholder et hav av praksiser og andre tips til praktisk og pragmatisk utvikling – både for team og individuelle utviklere. Boken står for smidighet og kritisk tenking, oppfordrer til nysgjerrighet, og legger vekt på nødvendigheten av å stadig utvide og foredle ens kunnskaper og ferdigheter.

Mange av mine lesere har nok lest den allerede, og nå har også jeg endelig gjort det!

The Pragmatic Programmer er en god introduksjon for relativt ferske utviklere, eller mer erfarne utviklere som ikke har vært eksponert for praksisene og prinsippene tidligere. For meg personlig var det ikke så mye å hente da jeg leste den nå – etter å ha vært en aktiv smidig utvikler i noen år. Den inneholdt noen gullkorn som også jeg kunne ha nytte av, men stort sett var det kun oppfriskning av velkjent stoff.

Likevel er boken fortsatt, selv om den ble skrevet for 12 år siden, ganske frisk og aktuell, og passer for dem som vil kalle seg software craftsmen. Den går ikke veldig i dybden på temaene den tar opp, og satset i stedet på å dekke mange fasetter av det å programmere.

Det meste jeg leste var jeg veldig enig i, men det var også enkelte tips og prinsipper jeg ikke støtter. For å være ærlig synes jeg tittelen burde ha vært The Pragmatic Programmer: From Apprentice to Journeyman. Den er nemlig skrevet for dem med kun litt erfaring, og vil ta deg et stykke på veien – men ikke tale om at du vil bli noen “mester” av å lese boken.

Etter å ha skrevet The Pragmatic Programmer sammen ble Andy Hunt og Dave Thomas forretningspartnere, og publiserer nå bøker for og av programmerere under navnet The Pragmatic Bookshelf. Her finner du noen av mine favorittbøker, blant andre Seven Languages in Seven Weeks og Pragmatic Thinking & Learning. Andre, relativt kjente bøker i serier inkluderer Learn to Program, The Passionate Programmer, The RSpec Book, Ship It! og Release It!. 

En lignende bok jeg har blogget om tidligere er Code Complete.

Det er på tide med et gjensyn med de små tegneserieheltene mine. Denne gangen dreier det seg om effekten av å ha mange utviklere som jobber på det samme prosjektet.

Jeg har alltid sagt at jeg foretrekker å jobbe i små utviklingteam. Størrelsen på et team har mye å si for hvilke utfordringer man får, og hvilke resultater man kan oppnå. Historien presentert over er ikke intuitiv, men har likevel endel sannhet i seg.

Et viktig stikkord er kommunikasjon. Etterhvert som et team vokser øker også antall kommunikasjonspunkter internt i teamet, og dermed også antall steder hvor kommunikasjonen kan bryte sammen. Tiden man må dedikere til kommunikasjon øker også betraktelig (figur 1 og 2).

Sammarbeid er vanskelig! Vi fokuserer mye på å lære å bli gode programmerere, men glemmer ofte at sammarbeid er en helt egen og veldig viktig ferdighet alle team-medlemmene trenger.

For å begrense problemene med kommunikasjon i større team legger man mere vekt på formaliteter, planlegging og dokumentasjon. I tillegg kommer man ofte opp med rollen teamleder. Et tradisjonelt utviklingsteam har en sentral leder som styrer utviklerne. Denne lederen skal fungere som et kommunikasjons-nav mellom utviklerne (figur 3). Han/hun får den ekstremt vanskelige oppgaven å sanke inn all den informasjonen som er viktig fra hver utvikler, og distribuere dem som trenger det. Det sier seg selv at man blir veldig sårbar for “feil” i dette leddet.

Og fleksibiliteten er borte… Etterhvert som smidig/agile har blitt populært har man lagt mindre fokus på å ha en sentral, styrende leder, og begrenser mengden planlegging, dokumentasjon og andre formaliteter – for at man skal kunne være mer fleksibel. Et lite team er da helt nødvendig.

Men det finnes også ulemper med små team; de er mere sårbare for forstyrrelser, sykefravær og slike ting.

En teknikk som hjelper på kommunikasjonen i teamet, og som muliggjør team bestående av flere utviklere, er utstrakt bruk av parprogrammering. Når utviklere jobber i par fokuserer to og to utviklere på den samme oppgaven, og kommunikasjonen dem imellom er svært tett og forhåpentligvis god. Antall øvrige kommunikasjonslinjer reduseres (figur 4).

Men husk at parprogrammering også er vanskelig, en ferdighet man må trene opp.

Solo-utviklere bedre enn team?

Det finnes dem som hevder at det optimale teamet kun består av én utvikler. I artikkelen Why a Great Individual Is Better Than a Good Team sier Jeff Stibel at det er vanskelig å finne dyktige personer, men at hver av dem er verdt et uendelig antall middelmådige personer. Ikke bare det, men dyktige enkeltpersoner er ofte mer verdifulle enn grupper/team som inkluderer dyktige personer.

Når vi blir en del av et team synker nemlig vår evne til å yte – blant annet på grunn av kommunikasjonsutfordringen. Stibel sier:

“When an activity can be performed sufficiently by one person with adequate skills, doing the activity as a group should be avoided.”

I 2009 blogget jeg om menneske-problemet, hvor det blant annet refereres til forskning som påstår at dyktige programmerere kan være opp til 28 ganger bedre enn dårlige programmerere. Om du har en slik utvikler i stallen din, eller er en slik selv, så må du være klar over at for å ta ut potensialet i en team-setting så må man trene på kommunikasjon og sammarbeid, og fjerne det man kan av barriærer og muligheter for kommunikasjonssvikt og feil.

Har du positive erfaringer fra å delta i et større utviklingsteam? Hvordan var teamet organisert? Hva ble gjort for å sørge for at alle kunne bidra optimalt? Del gjerne dine meninger i kommentarfeltet.

PS: Jeg snakker ikke her om å sammarbeide med dedikerte testere, driftsfolk, eller personer med forretningskompetanse. Dette er selvsagt viktig i mange sammenhenger. Denne artikkelen omhandlet spesifikt team av programmerere.

Andre relaterte artikler: En smidig teamleder | Utviklerprofiler og fire ferdighetskategorier | Parprogrammering ansikt-til-ansikt | Egoløs programmering: De 10 bud