Category Archives: Norsk

Articles in Norwegian

Hva burde egentlig et norsk IT-prosjekt koste?

Er det noen som sammenligner omfang og kostnad på IT prosjekter i Norge? Jeg tror man kunne få noen interessante innsikter dersom man gjorde dette riktig.

(Jeg må unnskylde at teksten i denne blogposten blir litt vag – jeg ønsker å si så lite som mulig om de aktuelle prosjektene for å unngå å eksponere andre)

Akkurat når jeg var involvert i et tilbudsarbeid for et prosjekt, var jeg samtidig involert i den endelige godkjenningen av et annet prosjekt. Jeg stusset over den store forskjellen i kostnadsramme for disse to prosjektene. Problemstillingen gikk lenge og gnagde og etter en lang tid ble jeg bevisst på at de to prosjektene hadde nesten helt likt forretningsmessig omfang. Hvorfor hadde de så forskjellige kostnadsforventninger?

Begge prosjektene var løsninger som hadde noen hundre saksbehandlere spredd i noen titalls lokalkontorer som behandlet noen titusentalls forretningstransaksjoner i året. I begge tilfellene var det cirka 20 forskjellige typer forretningstransaksjoner og disse hadde cirka 50% like behandligssteg, cirka 25% av behandlingsstegene var sammenlignbare og cirka 25% av behandlingsstegene var unike per type forretningstransaksjonene. Begge prosjektene skulle produsere og arkivere dokumenter og integrere med en håndfull andre systemer i og utenfor virksomheten.

Føringene rundt teknologi, arkitektur og prosjektledelse var nok forskjellige i de to prosjektene. Men omfanget av hva de skulle gjøre virket for meg veldig sammenlignbart.

Og forskjellen i kostnadsrammer? Jeg har ikke tilgang til offisielle budsjettall for de to prosjektene, men vi snakker om en faktor på 5x-10x. Dette er dramatisk.

Er det noen som har gjort en systematisk objektiv innsamling av IT-prosjektene i Norge? Ville ikke dette være et interessant forskningsprosjekt?

Posted in Non-technical, Norsk, Software Development | Leave a comment

Er IT-prosjektenes tid forbi?

Man kan lese fra moderne tanker på IT-utvikling at prosjekter er en avleggs arbeidsform. For de som har erfaring med utviklingsaktiviteter innen offentlig og privat sektor kan dette virke som en rar påstand. De aller fleste ser behovet for å unngå store prosjekter, men er prosjektet som arbeidsform virkelig avleggs?

Det spør naturligvis på hva man mener: I alle de årene jeg har jobbet med IT-utvikling er det en ting som er sikkert. Arbeidet endrer seg til det bedre når man går fra å bygge noe på laben og over til å lansere programvaren for brukere som benytter seg av den til daglig. Før dette tidspunktet er “kvalitet” en subjektiv og spekulativ egenskap, “fremdrift” er et begrep som må kvalifiseres med mange forbehold og formålet til hele initiativet er fortatt en hypotese der alle har sin egen tolkning.

I dag er den ingen gode grunner til å levere programvare gjennom et prosjekt som sitter flere kvartal eller år og bygger noe som så skal være klart til en stor lanseringsdag. I den betydningen er prosjekter en avleggs modell.

Men noen ting har ikke endret seg: Mange organisasjoner vil ha behov for et team som er større i en periode – et prosjektteam. Mange organisasjoner kunne ha verdi av leverandører som kan ta ansvar for at det arbeidet som gjøres er av god kvalitet og har en rimelig kostnad.

Men organisasjonen gjør smart i å koble dette prosjektteamet tett opp mot den mer permanente organisasjonen. Linjeorganisasjonen kjenner behovet og rammevilkårene bedre enn den midlertidige organisasjonen og vil ta over forvaltningen av produktet på sikt.

Og nye produkter vil ikke lanseres dager eller en gang uker etter at de har blitt påbegynt. Ved å levere så ofte som hver uke eller endog flere ganger om dagen kan organisasjoner heve kvaliteten og redusere arbeidet og bekymringen i forbindelsen med nye leveranser. Men det er ikke gjort på en dag. Dersom man skal etablere et nytt prosjekt kan man med fordel drifte dette (for eksempel i en skybasert løsning) allerede etter få dagers utviklingsjobb. Men det vil ta noen måneder før man har nok funksjonalitet til at man ønsker å invitere noen utenfor prosjektet til å bruke løsningen.

Er IT-prosjektenes tid forbi? Jeg håper vi ikke lenger vil se initiativene som bruker titalls eller hundretalls millioner kroner før man lanserer noe for brukere. Men organisasjoner vil fortsatt måtte benytte seg av økt bemanning i satsningsperioder. Og nye produkter bygges ikke på en dag før de kan lanseres.

Posted in Agile Release Patterns, Non-technical, Norsk, Software Development | Leave a comment

Software 2015 i regi av DND

Jeg sitter i styret i Dataforeningen Østlandet hvor jeg er med å arrangerer Software 2015. Software er en kryssfaglig IT-konferanse hvor vi samler spesialister innenfor forskjellige fagfelt for å få dem til å snakke sammen på tvers av fagområdene.

På konferansen er det dagsaktuelle temaer og trender som står på programmet. Jeg er stolt av alle de spennende temaene faggruppene har tatt fram og samarbeidet vi har fått til på tvers av fagmiljøer.

Vi ser at både kravhåndtering, devops, prosjektledelse og arkitektur fokuserer mer og mer på å bevege seg mot kortere leveransesykluser. Da blir det viktig å forstå verktøyene og teknikkene som gjør dette mulig.

Et annet viktig tema er den stadig mer sentrale rollen IT spiller i samfunnet. Vi har samlet representanter fra store offentlige IT-miljøer som gjennomfører prosjekter som vil påvirke alle i Norge.

Software har også lykkes i å belyse den viktige debatten som skjer mellom sikkerhet, personvern, kriminalitetet og overvåkning i samfunnet.

Jeg synes også det var morsomt å snakke med Frode som er med å arrangere stormaskinsporet. Jeg har aldri satt meg nok inn i stormaskin, men har vært i flere organisasjoner der hjertet av virksomheten har ligget i stormaskinen. Det har som regel vært en målsetning å bli kvitt stormaskinen, men fordi man ikke har satt seg inn i hva den gjør blir dette veldig vanskelig. Frode sa: “De som vil bli kvitt stormaskinen setter seg ikke inn i hva den gjør – så de får det ikke til. Og de som setter seg inn i den vil ikke bli kvitt den”. Jeg er ikke 100% overbevist om at han har rett, men det er spennende tanker.

Meld deg på Software 2015 du også.

Jeg gleder meg, og håper å se deg også på Software 2015!

Posted in Non-technical, Norsk | Leave a comment

Om å løse alt bortsett fra det egentlige problemet

“Problemet med Java er at det krever så mange abstraksjoner. Factories, proxies, rammeverk…” Min samtalepartner gjenfortalte inntrykket han hadde av de Java-programmerende kollegene sine.

Jeg måtte innrømme at jeg kjente meg igjen. Kulturen rundt Java-programmering har noen sykdomstrekk. Kanskje det minst flatterende er fascinasjonen for komplekse teknologiske løsninger. Et gjennomsnittlig Java-prosjekt har rammeverk (Spring, Hibernate), tjenestebusser – gjerne flere (OSB, Camel, Mule), byggverktøy (Maven, Ant, Gradle), persisteringsverktøy (JPA, Hibernate), kodegeneratorer (JAXB, JAX-WS), meldingskøer (JMS), webrammeverk (JSF, Wicket, Spring-MVC) og applikasjonsservere (WebSphere, WebLogic, JBoss). Og det er bare starten. Hvor kommer denne impulsen fra?

Jeg har hørt to teorier om hvorfor Java-programmerere ender opp med en kompleks hverdag. Den ene skylder på sjefene, mens den andre skylder på programmererne. Jeg vil ta for meg begge og peke på en vei ut av jungelen.

Teori 1: Steak and strippers

Zed Shaw, mannen bak “The motherfucking manifesto for programming, motherfuckers” skylder på IT-sjefene. Han mener at selgerne fra teknologiske giganter tar med IT-sjefer ut på strippebuler og kjøper biffmiddager til dem. Og vips så kjøper IT-sjefen inn et ubrukelig verktøy som programmererne er tvunget til å bruke. (Zed påpeker at det vil være positivt med flere kvinnelige IT-sjefer, ettersom de i det minste ikke vil være like interessert i strippebulene)

Ref: Zed Shaw: Control and responsibility (http://zedshaw.com/essays/control_and_responsibility.html). Zed Shaw: Programming, motherfuckers (http://programming-motherfucker.com/). Zed Shaw: Video – Steak and Strippers (http://vimeo.com/2723800).

Argumentet er underholdende, men forklarer bare en del av problemet. Mange av verktøyene som står bak kompleksiteten i Java-prosjekter er åpen kildekode og selges typisk ikke av selgere med fete representasjonskontoer.

Teori 2: Blinkende lys

Jeg tror en viktigere teori er at programmerere er opptatt av fancy ting som blinker. Enkle ting som firmaet tjener penger på er kjedelige. Å sette seg ned og flytte data fra databasen og putte det i en webside er kjedelig for en programmerere. Å lære seg et nytt rammeverk som gjør den samme jobben på en fancy måte er spennende. Å fjerne teknologier og lage en enklere løsning er kjedelig. Å innføre et rammeverk som skal skru sammen teknologien er spennende.

Alle foretrekker å gjøre det de synes er spennende. Jeg vet det, for jeg har vært der selv.

Grunnleggende sett tror jeg at Java-programmere selv har skaffet seg de problemene de ofte klager over med komplekse teknologier.

Veien ut av villmarken

For meg var det viktigste skrittet ut av villmarken foredraget jeg hold på JavaZone for to år siden. I foredraget bygger jeg og Anders Karlsen en webapplikasjon i Java uten å bruke webrammeverk. (Innbild deg at du hører et ironisk gisp her)

Jeg har øvet meg på å løse de problemene jeg har i prosjekter med å bruke enklere teknologier. Slik vet jeg hva de komplekse løsningen gjør. Og så langt er det nesten ingen løsninger som ikke innfører mer problemer enn de fjerner. Det de gjør er at de flytter fokuset fra den oppgaven programmet egentlig skulle løse over til alle de teknologiske delene som man skal få til å fungere sammen.

Jeg tror ikke programmerere er bedre eller dårlige enn andre mennesker når det gjelder det. Men vi har alle en tendens til å bruke tiden vår til å finne spennende problemer å løse i stedet for å løse det vi egentlig skulle på en naiv og enkel måte. Min far sa det egentlig best: Du bør ikke bruke en kalkulator før du kan løse de samme regnestykkene på papir.

Posted in Java, Non-technical, Norsk, Software Development | 27 Comments

Husk å melde deg på til Smidig 2010

Smidig 2010: Norges største smidige konferanse

Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort!

Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

Posted in Extreme Programming, Non-technical, Norsk | Leave a comment

Å trene på Java EE

For å bli bedre må man trene. For å bli bedre med avanserte ting, må man forstå de grunnleggende tingene bra. For å vite hvorfor man bruker avanserte verktøy, må man prøve å jobbe uten dem. Derfor har jeg de siste ukene trent mange ganger på å lage en veldig enkel webapplikasjon i Java. For hele applikasjonen har jeg startet med å skrive testene før koden som implementerer funksjonaliteten.

Dersom du vil prøve deg på samme øvelse, inneholder denne artikkelen litt informasjon for å komme i gang. Start med koden under og følg feilmeldingene. Send en kommentar dersom du ikke kommer videre fra en feilmelding, så får vi en FAQ.

Oppgaven

Løs et så enkelt som mulig problem som involverer websider og database med så enkel teknologi om mulig.

Oppgaven jeg har laget går ut på å opprette personer med fullt navn og søke etter personer basert på navnet deres. For å gjøre oppgaven så lite som mulig har jeg valgt å la personer kun ha ett informasjonsfelt: Fullt navn. Denne oppgaven tar cirka 2-3 timer uten øvelse og du kan få den ned i 60-90 minutter med trening.

Du kan naturligvis velge en annen oppgave, men uansett hva du velger: Det er mer lærerikt å gjenta den samme oppgaven flere ganger enn å utføre en avansert oppgave.

Når jeg utfører oppgaven er det viktigste jeg lærer meg å forstå feilmeldingene som guider meg gjennom utviklingen. Dersom du trenger hjelp til å komme til de første feilmeldingene kan du se resten av artikkelen.

Steg for steg: Startpunktet

Selv om jeg valgte veldig enkel teknologi for implementasjonen, har jeg valgt et større sett med biblioteker for å skrive testene. Jeg bruker følgende når jeg skriver testene:

  • JUnit 4.6
  • Jetty 6.1.22
  • HSqlDb 1.8.0.10
  • WebDriver-HtmlUnit 0.6.1039
  • Mockito 1.8.0
  • FEST-assert 1.2 (ikke påkrevd, men gjør testene søtere)

Den eneste teknologien jeg har valgt for implementasjonen er Servlet-API 2.5 og Hibernate-Annotations 3.4.0.GA.

For at du skal slippe å plundre så mye med avhengigheter før du kommer i gang har jeg laget en pom.xml-fil som du kan ta utgangspunkt i.

Web-tester

For å starte utviklingen, er det lurt med en test som starter på utsiden av applikasjonen. Noe slikt:

  1. Start opp miljøet
  2. Legg inn en person
  3. Søk etter personen

Slik kommer du i gang med en test som går mot en web applikasjon:

Dette oppsettet forventer å finne web.xml-fila på src/main/webapp/WEB-INF/web.xml.

Funksjonell test

En funksjonell test definerer kravene i applikasjonen. Det er lurt å gjøre funksjonelle tester så raske som overhode mulig, samtidig som de går gjennom alle kravene. En funksjonell test trenger ikke være en ende-til-ende test, slik som eksempelet over. Dette er viktig, fordi ende-til-ende tester er ofte veldig trege. Her er noen eksempler på funksjonelle tester:

  • Vis en siden for å opprette nye personer
  • Opprett en ny person
  • Verifiser at personens navn er oppgitt og ikke inneholder ulovlige tegn
  • Vis en side for å søke etter personer
  • Vis alle personer dersom søkestreng ikke er angitt
  • Søk etter angitt søkestreng

En funksjonell test kan se slik ut:

Data-aksess-test

Hibernate forenkler databasebruken mye. Men Hibernate er selv komplekst og når man bruker det på mer avanserte måter fortjener det egne tester. En typisk test med Hibernate kan være:

  1. Legg i tre personer i database
  2. Søk etter en del av navnet på en av dem
  3. Sjekk at du får tilbake akkurat den du forventet

Når jeg starter med Hibernate, lager jeg en test som dette, og følger feilmeldingene. Pass på å både følge feilmeldinger i loggen og stack tracer.

Følg feilmeldingene herfra.

Integrasjon

En veldig vanlig måte for web serveren å overlevere spesielt ting som DataSources til applikasjonen er via JNDI. I Jetty kan du gjøre dette i Web-testen på følgende måte:

Konklusjon

Å gjøre en liten øvelse som dette er en god måte å bli bevisst hvilke vaner du har og hvor lang tid det egentlig tar for deg å gjøre oppgavene dine. Du vil oppleve at det å skrive tester før koden føles som om det går saktere enn du tror du er vant til.

Men dersom du er som meg, vil du også oppleve noe annet: Når du tester ut applikasjonen første gang (du kan gjøre dette med Jetty, naturligvis) så er sjansene gode for at den vil være nokså feilfri og at debugging i stor grad er overflødig. Jeg vet ikke med deg, men debugging er en aktivitet jeg gjerne blir kvitt.

Posted in Extreme Programming, Java, Norsk, Software Development | 18 Comments

Tips for databasemigreringer

En kollega spurte i dag om mine topp tips når det gjelder databaserefactorings. Her var mitt svar:

  1. Ha en organisert struktur med at man gjennomfører navngitte migreringer (a la Ruby-on-Rails sine migrations eller dbdeploy). Typisk er det vanlig og velfungerende å navngi scripts med løpenummer (001, 002, …) eller timestamp (20091124071300, …) og ha en tabell i databasen som holder styr på hva som har blitt kjørt
  2. Bruk views og materialiserte views for å støtte tilbakekompabilitet (NB: Oracle er veldig sterk på dette, andre databaser kan slite)
  3. Om mulig, gjør hver migrering bakoverkompatibel på en versjon av programvaren. Dette er lettere å få til jo hyppigere du releaser programvaren
  4. Skill endringer i skjema (for eksempel: legg på en kolonne) fra migrering av data (for eksempel: populere kolonnen). Feilene vil typisk ligge i #2 av disse, og den er lett å gjøre transaksjonell, mens skjemaendringer ikke er transaksjonelle i de fleste baser.

Har jeg dekket det viktigste da?

Posted in Norsk, Software Development | 17 Comments