Forfatterarkiv: Marius

Om Marius

Marius er utvikler i Shortcut. Han har enda ikke bestemt seg for hva han skal bli når han blir stor; egentlig er han samfunnsviter, hans første jobb var som restaurantsjef, men størsteparten av sitt yrkesaktive liv har han jobbet med utvikling. Marius jobber med web og Ruby i Shortcut.

Kunsten å gå skikkelig på trynet

Publisert av

Thomas Watson, grunnleggeren av IBM, er kjent for å ha sagt at den enkleste måten å lykkes raskere er å doble feilraten sin. 3M – selskapet bak Post-it, som var en arbeidsulykke – er kjent for å dele ut bonus til ansatte som lager produkter som flopper i markedet. Vi har til og med et noe forslitt ordtak: det er av feilene sine man lærer.

Grunnen er åpenbar: de færreste av oss er så geniale at vi lykkes med alt vi gjør. I snitt kan man antakelig regne med at vi lykkes med en mer eller mindre fast andel av prosjektene våre. Gitt at andelen vellykkete prosjekter er fast gir det mening å prøve mange forskjellige ting. Samtidig kan vi lære nyttige ting av feilene vi gjør.

En bransje i traume

På begynnelsen av 90-tallet gikk mer eller mindre hele den norske banksektoren konkurs. Staten måtte redde bankene med skattebetalernes penger, og overtok styringen av de største bankene. Noe av det første man satte i gang med var å finne de ansvarlige bak fadesen. I en bransje som i bunn og grunn lever av å ta risiko er man vant til å måtte ta konsekvensene når man har tatt for stor risiko. Men mitt inntrykk er at den blame-stormingen som foregikk i de store norske bankene etter bankkrisen traumatiserte store deler av bransjen i lang tid.

Husker du Copland?

Da jeg startet mitt kjærlighetsforhold til Apple var det en kar som het Michael Spindler som satt bak roret i Apple, etter at John Sculley sendte Steve Jobs ut noen år tidligere. Apple lanserte på denne tiden en rekke spennende produkter: PDA-en Newton, Claris Works, flere titalls forskjellige Macintoshmaskiner med navn som Centris, Performa, LC, Quadra, spennende teknologier som OpenDoc – og vi som brukte Mac ventet på det nye operativsystemet som skulle komme: Copland. På den tida ble det dessuten lisensprodusert Macintosh-kompatible maskiner av selskaper som Power Computing og Radius. Copland kom aldri, og ingen av disse produktene finnes idag. Apple gikk skikkelig på trynet, rett og slett.

Buzz

Da Google lanserte Buzz gikk det aller meste galt. Ikke bare introduserte de noen privacy-problemer fra helvete, det var også få som skjønner hva man skal med denne tjenesten. Jeg skjønner det fortsatt ikke. Vet du hva? Det betyr nesten ingen ting. Googles suksess avhenger ikke av om Buzz (eller Google TV) lykkes, og det tror jeg Google vet. Google har idag to konkurrerende operativsystemer for tablet-PCer: Android og Chrome OS. Ingen vet om web- eller native apps er framtida; ved å spille på to hester dobler Google vinnersjansene.

Prove me wrong

Spåmenn jobber for å bevise at de har rett: i det de tar feil er liksom litt av vitsen borte. Dyktige utviklere, designere og markedsanalytikere jobber istedet for å bevise at de tar feil; istedet for å spekulere i hva framtida kommer til å bringe lager vi ting og tilbyr dem på markedet. Hvis ingen vil ha det vi har laget lager vi noe nytt.

Spåmannen har krystallkula, vi andre har kunder.

Du kommer til å feile, bli vant til det

En stor fordel med å gjøre feil er at man venner seg til det. Før eller siden gjør alle feil, og da er det en stor fordel å være vant til det. Ikke blir fallhøyden så stor heller.

Know when to hold’em, know when to fold’em

For oss som gjør feil er det viktig å innse at man tar feil på riktig tidspunkt. Gir du opp for tidlig kommer du antakelig aldri til å lykkes ordentlig med noe; de aller fleste ting krever mye mer arbeid enn man skulle tro. Jeg har selv vært med på mange prosjekter jeg den dag idag tror kunne lykkes, om jeg hadde giddet å gjøre det ordentlig.

På den andre siden kan enhver aksjespekulant fortelle deg hvor vanskelig det er å selge en aksje med tap. Jo mer du har investert i noe, jo vanskeligere er det å kvitte seg med det.

#fail

Helt til slutt: ikke la deg stoppe av skittkasting fra andre. Skittkasting mot andre er en effektiv måte å overbevise seg selv om at man gjør rett i å ikke våge å gå for ideene sine.

Ubuntu mener alvor

Publisert av

Mark Shuttleworth startet selskapet Thawte i 1995, som han i 1999 solgte til Verisign for 575 millioner dollar. Etter å ha brukt en del av disse pengene på å bli historiens andre betalende romturist startet han i 2004 selskapet Canonical, som har som mål å støtte prosjekter innenfor fri programvare.

Canonical lanserte i 2004 første versjon av operativsystemet Ubuntu, basert på Linuxdistribusjonen Debian. Ubuntu har fått sitt navn fra det sørafrikanske ordet for humanity towards other, og kaller seg Linux for Human beings. Der Linux av mange har blitt oppfattet som et operativsystemer for nerder og urealistiske idealister satser Ubuntu stort på brukervennlighet og et konsitent brukergrensesnitt.

Kontrovers

I siste versjon av Ubuntu, Lucid Lynx, valgte man å flytte standardknappene i vinduer (lukk, minimer, maksimer) fra høyre til venstre side av vinduet. Dette førte til store protester i Ubuntumiljøet, der folk følte seg forbigått da dette valget ble gjort. Shuttleworth svarer på protestene ved å si:

This is a difference between Ubuntu and several other community distributions. It may feel less democratic, but it’s more meritocratic, and most importantly it means (a) we should have the best people making any given decision, and (b) it’s worth investing your time to become the best person to make certain decisions, because you should have that competence recognised and rewarded with the freedom to make hard decisions and not get second-guessed all the time.

Han avslutter med å si

This is not a democracy. Good feedback, good data, are welcome. But we are not voting on design decisions.

Etter min oppfatning tar her Shuttleworth grep om hvordan Ubuntu skal framstå, dette er en av grunnene til at Ubunbtu vinner nye tilhengere hver dag. Brukere av et operativsystem (eller et hvilket som helst program) vil ha en gjennomtenkt og helhetlig opplevelse; dette er en av hovedgrunnene til at Macbrukere er så glad i operativsystemet sitt.

Appstore for Ubuntu

I motsetning til brukere av Mac OS og Windows er Linuxbrukere vant til å finne og installere programvare innenfor operativsystemet sitt. Siden Ubuntu er basert på Debian finnes i overkant av 30.000 programmer man kan installere fra et eget program i operativsystemet. Istedet for å finne fram til et nettsted, laste ned en .exe eller .dmg-fil og håpe de som har laget programmet er til å stole på kan Ubuntu/Debian-brukere velge blant disse programmene – som alle er kvalitetssikret av de som lager operativsystemet.

En ulempe med dette er at det kan være vanskelig å finne fram til det beste programmet for å utføre en oppgave. Hvis man for eksempel skal høre på musikk kan man velge mellom flere hundre programmer til dette; noen gode, noen dårlige.

Ubuntu kom derfor i forrige versjon med sin «Ubuntu software center», som viser et utvalg av programmer som Canonical mener er best. De har en egen seksjon for «featured applications» med programmer som er godt vedlikeholdt og fungerer godt med resten av operativsystemet. De neste versjonene av Software center kommer med støtte for rating av applikasjoner og distribusjon av programmer som ikke er fri programvare.

Dette er enda en av beslutningene til Ubuntu som setter brukeren i sentrum, og vil nok være vanskelig å svelge for tradisjonelle Linuxbrukere. Samtidig er det det første forsøket på å gjenskape en «appstore» a la den Apple har for iPhone/iPad. Jeg er ganske sikker på at dette er en modell for distribusjon av programvare som har framtiden foran seg også på PC-en.

Hvis man ser på den suksessen Linux har hatt i serverrommene er det ingen teknisk grunn til at dette operativsystemet ikke skal kunne ha tilsvarende suksess på PC-ene til helt vanlige folk. Jeg tror dette handler om markedsføring, tilgjengelighet og en overordnet visjon for hvordan brukeropplevelsen skal være; teknologien finnes allerede.

Her stiller Canonical og Ubuntu med en tilnærming jeg tror vi kan følge med spenning.

Fri programvare gir raskere applikasjoner

Publisert av

For et drøyt halvår siden publiserte Shortcut kildekoden til Trafikanten for Android på Gitorious.org. Jeg laget denne applikasjonen for å bli kjent med Androidplattformen, og for å få tilgang på sanntidsopplysninger på min Androidtelefon.

Trafikantens betingelser for bruk tillater ikke kommersiell bruk av deres data, så dette prosjektet vil alltid være et fritidsprosjekt. Min hovedmotivasjon for å frigi kildekoden og oppfordre til bidrag fra andre utviklere var derfor å se hvor mye flere utviklere kunne få gjort ved å bidra med litt fritid hver.

User serviceable parts inside

Vi oppfordret til å lage sin kopi av kildekoden (en clone i Git-språket) og gjøre de endringene man ønsker. Disse endringene kan så samles til en merge request, som er et begrep Gitorious har for å be noen om å ta i bruk endringer en selv har laget.

Androids market er ikke fullt så mye sirkus som Apples Appstore. Ettersom det enn så lenge ikke er mulig å ta betalt for applikasjoner mot norske brukere bærer det preg av dugnadsånd, pionervirksomhet og glade amatører som meg. De første anmeldelsene av Trafikanten-appen var relativt entydige:

Kan bli en bra app, men har foreløpig ubrukelig trege søk

Applikasjonen var treg.

Gjør det bedre selv hvis du kan

Øystein Gulliksen var raskt ute med første bidrag i juni: posisjonering ved hjelp av GSM-sendere, som gjorde at søk etter stoppesteder i nærheten gikk raskere.

Så, for tre måneder siden, dukket det opp en mail til meg fra Gitorious. Simon Skrede hadde sendt inn en merge request der han fjernet noe kode som ikke var i bruk. Resultatet? Applikasjonen kjørte nå raskere.

Så, for et par uker siden, fikk jeg en ny merge request på Gitorious, der Marius Gravdahl hadde lagt inn støtte for live folders (at man får en «mappe» på skrivebordet på telefonen som viser sist brukte stoppesteder, klikker man på dem går man inn i applikasjonen). Marius fortsatte å sende merge requests, han har gjort en enorm jobb med stabilitet og ytelse, og har egenhendig gjort at applikasjonens gjennomsnittrating har økt. Samtidig viser Googles statistikk at antall installerte versjoner øker og at folk fortsetter å ha applikasjonen installert (1671 installasjoner, 63% av disse bruker applikasjonen).

Jeg har nå laget en egen gruppe på Gitorious og dermed gitt Marius Gravdahl tilgang til å publisere direkte til den opprinnelige applikasjonen på Gitorious. I virkeligheten er det ham som bidrar mest til dette prosjektet nå, jeg bare startet det.

Bortsett fra at Androidbrukere nå har en bra sanntidsapplikasjon tilgjengelig synes jeg noe av det mest interessante med denne historien er prosessen jeg har sett. Dette er, slik jeg ser det, noen av suksessfaktorene:

  1. Fri programvare inviterer til bidrag. Ved å frigi kildekoden til et program åpner man for at den som bruker programmet kan endre det slik at det fungerer bedre for ham. Det er dette som er essensen i fri programvare. Av de 1600 som har installert programmet er det fire-fem (som jeg vet om) som har gjort endringer i det. Det er ikke noe høyt tall, men gjenspeiler vel omtrent forholdet mellom «brukere» og «utviklere» av programvare.
  2. Distribuert versjonskontroll  muliggjør deling. Den neste faktoren som har gjort prosessen mulig er at vi bruker distribuert versjonskontroll – Git. Med git kan andre utviklere jobbe videre med et prosjekt og publisere sine endringer til andre. Vi har nok enda bare sett toppen av dette isfjellet; de fleste prosjekter som bruker Git (dette inkludert) opererer fortsatt med en «offisiell» hovedgren av prosjektet.
  3. Sosial programmering er framtida. Gitorious har også vært en suksessfaktor i å få dette til. På Gitorious var det mulig for bidragsyterne å hente kildekoden og publisere sine endringer. Ved å lage en merge request kan bidragsyterne når de er ferdige med et stykke funksjonalitet si fra at de har noe de ønsker integrert, og Gitorious har en prosess rundt kvalitetssikring og integrering av dette. Den siste merge requesten består for eksempel av tre versjoner, der bidragsyteren har gjort oppdateringer i selve merge requesten etter at den ble laget.
  4. En åpen plattform vinner i lengden. I disse iPad-dager er dette noe ikke så mange tilsynelatende er opptatt av, men det at Android er en åpen plattform og selv er fri programvare er for mange et vektig argument for denne plattformen. Jeg tiltrekkes av Android nettopp fordi den gir meg som utvikler større frihet. Som jeg nevnte er det bare fire av 1600 av denne applikasjonen sine brukere som har bidratt til kildekoden, men her er det nettopp dette som har gjort at den er blitt såpass bra. «Vanlige brukere» av en applikasjon tjener altså på at «hackerne» kan endre på den, på samme måte som eiere av en bil tjener på at mekanikeren kan gjøre endringer på bilen uten å kontakte produsenten.

På samme måte som Trafikanten på Android kan forbedres av utviklere kan også Android selv – altså operativsystemet på telefonen – forbedres av utviklere utenfor Google. Jeg tror dette på sikt vil gjøre Android til en bedre plattform enn dens proprietære konkurrenter, og jeg tror prosessen som kommer til å sørge for det er den samme prosessen som har gjort denne lille applikasjonen så mye bedre det siste halve året.

Kravspesifikasjon – den umulige kunsten å beskrive noe som ikke finnes

Publisert av

Kravspesifikasjonen er dokumentet som fullstendig beskriver det som ikke ennå finnes, på en måte som gjør at ingen kan misforstå den. Den perfekte kravspesifikasjonen – gitt at noe sånt faktisk kan lages – er så utfyllende, entydig, gjennomtenkt og forståelig at hvem som helst skal kunne lage det den beskriver. Kravspesfikasjonen er jo også ofte laget for nettopp det: at man kan innhente tilbud fra flere leverandører og sammenligne det som effektivt skal være samme leveranse ut fra pris; siden alle leverandørene skal levere det samme er det bare prisen som skiller.

Sammenlign dette med hvordan prosjekter faktisk fungerer: etterhvert som man begynner å lage noe, lærer man hvor lite man egentlig visste om problemområdet. Etterhvert som brukere begynner å klikke på knapper ser man hva de egentlig trenger. Prosjekter er en læringsprosess, og kunnskapen man får underveis i prosjektet har enorm verdi. En «god» kravspesfikasjon eksisterer i en verden der dette ikke skjer, der lærdom man får underveis i prosjektet håndteres gjennom avviksprosesser (bare smak på det ordet…). En god kravspesifikasjon lar deg sette apekatter til å gjennomføre, men hvem vil egentlig jobbe sammen med apekatter (bortsett fra dyrepassere)?

Det finnes en rekke alternativer til den tradisjonelle kravspesifikasjonen når man skal lage programvare; de fleste har en ting til felles: tillit. Uten tillit mellom den som kjøper og den som leverer kan ikke engang den beste kravspesifikasjonen redde prosjektet. Og videre: om vi forutsetter et tillitsforhold mellom partene, trenger vi da den tradisjonelle kravspesfikasjonen?

En annerledes tilnærming

Jeg skal ikke gå i dybden på alternativene til kravspesifikasjonen her, det er antakelig mer enn nok stoff for en annen artikkel. Men en tidligere kollega av meg har skrevet en ganske annerledes måte å spesifisere et websystem som jeg synes var veldig interessant. Børre Austmann jobber i Human-Etisk Forbund (HEF), og ble for noen år siden med i en arbeidsgruppe for å utvikle et system HEF ønsket å lage for håndtering av deltakere i Humanistisk konfirmasjon og andre seremonier.

Etter å ha laget en omfattende og detaljert rapport til HEFs hovedstyre, fikk gruppen grønt lys for å gå videre, men samtidig signaler om at fremtidige innspill ikke måtte være så omfattende og detaljerte. Børre satte seg da ned og skrev et scenario fra år 2009 – altså noen år fram i tid – som beskrev hvordan noen oppdiktete personer forholdt seg til Humanistisk konfirmasjon.

Lene er 14 år, og har bestemt seg for Humanistisk konfirmasjon. Om påmeldingen beskriver scenariet blant annet:

I august åpner Lene på nytt nettsidene for å fylle ut påmeldingsskjemaet som hun finner på en link fra Grenland lokallags hjemmeside. Skjemaet er flersidig og oversiktlig. Første side er spørsmål om Lene – navn, fødselsdag, adresse, hennes mobil og epost, skole og klasse hun går i. Hun kan også velge om hun vil ha skjemaet på bokmål eller nynorsk. Hun velger bokmål. Språket i skjemaet og all korrespondanse vil være på det målføret hun har valgt.

HEF brukte dette scenariet som grunnlag til å innhente tilbud fra forskjellige leverandører, og fikk som tilbakemelding fra dem at dette var en spennende og annerledes måte å jobbe på.

Det elektroniske påmeldingsskjemaet kom allerede fire måneder senere. I dag melder nær 99% av konfirmantene seg til Humanistisk konfirmasjon på nett. HEFs ansatte i fylkene sparer til sammen massevis av timer i året på at manuelle prosesser er automatisert, timer de kan bruke på andre ting. Men det viktigste er kanskje at samarbeidet mellom HEF og leverandøren deres fortsatt er basert på tillit, og at begge parter er fornøyd med og stolt av det de har laget.

Scenario = brukerhistorier?

De som har jobbet med brukerhistorier kjenner dere kanskje igjen i denne måten å spesifisere på. Brukerhistorier er kjent fra smidig utvikling, og gir en måte for kunden å beskrive bruksområder av et system som skal lages. Extremeprogramming.com definerer blant annet brukerhistorier slik:

[User stories] are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.

I extreme programming bruker man brukerhistorier som grunnlag for akseptansetester, og er dermed en del av estimeringsprosessen: brukerhistorien konkretiseres i form av akseptansekriterier, som relativt entydig brukes for å oppnå enighet mellom kunden og leverandøren om at leveransen er ferdig. Scenariene som er beskrevet her er både lenger enn og har en mer litterær/emosjonell form og en lavere detaljeringsgrad enn en brukerhistorie.

Til slutt, siste avsnitt fra scenariet, der Lene (konfirmanten) og Reidar (fylkessekretæren) ser tilbake på seremonien:

Av kurslederen fikk hun en rose, en klem og kursbevis da hennes navn ble ropt opp. Rosa og klemmen sto det ingenting om i konfirmantbasen – men det var fra denne Reidar hadde kjørt ut kursbeviset hennes på fylkeskontorets skriver – rett fra nettet noen dager før, mens han sjøl løste sudokuen i Telemark Arbeiderblad.