Her er utviklernes 10 verste tabber

Vi har enten møtt dem, eller hørt om dem: Utviklerne som bruker votter og vintre på de enkleste oppdrag, og som gjerne skriver regning med hele bestikkskuffen til hjelp.

Det skulle ikke være så vanskelig. Gode verktøy er tilgjengelig, og konkurransen om de gode utviklerne er hard mellom plattformer og mellom oppdragsgiverne. Allikevel klarer utviklere å rote seg inn i en hengemyr av dårlig prosjektledere, feilslått praksis og tillært slurv.

I samarbeid med Computerworlds nyhetstjeneste, har vi sett litt på hva som kjennetegner dem, så er du advart.

Advarsel: Har du ikke opplevd slike ineffektive utviklere, har du mye å lære av de følgende punktene.

Ineffektiv praksis 1: La det gå dager mellom hver test

Om det ikke skrives kode, kan man alltids diskutere om det trengs en komponenttest eller en funksjonstest.

I mellomtiden gror skrevet kode til med potensielle feil. Kombiner det med ledere som ikke ser verdien av tester, siden det går med ekstra tid. Konsekvensen er forsinkete og dyr prosjekter med feil man ikke skulle tro var mulig.

Poenget er at det ikke spiller noen rolle hvilken test det er snakk om. Men grunnlaget for videre suksess for prosjektet ligger i at det som er laget er solid nok. Kontinuerlig testing fundamenterer denne plattformen. Solskinnsledere vil uansett hevde at sommeren 2012 i Norge var et lysende eksempel på norsk toppsommer – for dem er virkeligheten et uinteressant spesialeksempel, så test i vei og vær lykkelig.

Ineffektiv praksis 2: La det gå dager mellom hver delproduktbygging

Å tre tilbake og se helheten, eventuelt siste bidrag, er ikke bare lurt for dem som bygger skyskrapere. Men det har samme formål – at det ikke skal rase sammen på et impertinent tidspunkt.

Å sjekke hvordan den siste koden fungerer i helheten er blitt en smal sak med verktøy som virtuelle maskiner og for eksempel Jenkins CI. Oppsett av miljø som tar de fleste aspektene av tar noen timer, og deretter tar det minutter å lage en fersk arena for å prøve hele prosjektet fra gang til gang.

Du kan til og med automatisere byggingen av delprosjektene gjennom å bruke revisjonsverktøy som SVN eller Git. Innmating av nye komponenter, bygging og kjøring kan foregå automatisk, med varsler sendt og logger skrevet for det som går dårlig. Eller bra.

At prosjektet faktisk virker får hjertet til å banke. I prosjektet også.

Ineffektiv praksis 3: Bruk et tregt og vanskelig revisjonssystem

Det er med utviklere som med andre informasjonsmedarbeidere – gi dem et tregt verktøy, og det går tregt – også med å bruke verktøyet. Kjente prosjektrevisjonssystemer – som ClearCase – får medarbeidere til å «vente litt» med å sjekke kode er tidkrevende og øker risikoen i prosjektet. Evig «waitstate» i revisjonsverktøyet fra alle i prosjektet er like ille som om det oppstår i koden.

Risikoen øker blant annet fordi verdi av testing og mellombygg blir verdiløst. Sårbarheten er høy fordi ferdig kode blir liggende på et sted over tid, med konsekvensen det har for deling i prosjektet eller så prosaisk som tap av kode etter at en maskin feiler.

Finn og bruk et revisjonsverktøy som er effektivt og raskt – ikke la det være her du sparer prosjektkostnader.

Ineffektiv praksis 4: Lever alt til produksjon uten en siste fikserunde i strømmer

En fikserunde av kode i revisjonsverktøyer, der den dupliseres og sjekkes parallelt i hver sin strøm eller arm («branching»/»streaming»), gir effektiv sjekk og fiks.

Likevel sliter mange med verktøy som ikke tillater denne måten å la én kodebolk deles mellom flere slik at hver kontrollør sjekker et avgrenset område av koden samtidig med at andre sjekker andre deler av koden. Det korter ned revisjonen drastisk, gir raske lappemuligheter, og sender enda bedre kode ferdig til endelig produksjon.

Som i tre over er det et spørsmål om rett revisjonsverktøy. Og at prosjektmedarbeiderne vil og liker å bruke det.

Ineffektiv praksis 5: Kapasitetsjekken tas til slutt

Hvilken kapasitet, eller last, prosjektet kan håndtere utsettes ofte helt til slutt. Til og med svært effektive organisasjoner er så hengt opp i at det er totalen som skal bære. De glemmer også at det som bærer fortsatt ikke er sterkere enn det svakeste ledd.

Det henger også litt igjen i en kvasikreativ idé om at for tidlig optimering av kode ødelegger muligheter i prosjektet. Men hva om denne åpne holdningen i realiteten innebærer at du ikke aner om eller hvilken grense du setter for yteevne og skalering i prosjektet. Om dette er tidlig i prosjektet kan endring først til slutt bety enten store kostnader, lavere kapasitet fra start eller at kapasiteten ikke er i tråd med kundeforventningene fra starten.

Kapasitetssjekken er ikke nødvendigvis snakk om optimering av snutter, looper eller fragmenter. Det er snakk om å sjekke kapasiteten gitt type datalager, feil algoritmer, feil regelmotor eller fravær av gode samsvarssjekker før de gror til bremseklosser og flaskehalser.

Ineffektiv praksis 6: Utvikle i vei uten krav til kapasitet eller yteevne

OK, har prosjektet en idé om hvor mange brukere de vil ha eller vil få av det endelige produktet? Dette spørsmålet bør stilles så tidlig som mulig, og ikke etter at problemene med skalering eller yteevne oppstår. Spesielt om man slurver med denne testingen, og står der med skjegget fullt av postkasser helt til slutt i prosjektet, like før produktet er tenkt levert.

Her er det ikke bare snakk om god programmering, men også om rein forretning: Skal man levere til forventningene til kundene, bør man ha mer enn en vag idé om hva de forventer.

Ineffektiv praksis 7: Brukerne tas med på råd helt til slutt

Det er kanskje ikke så dumt å trekke en erfaring ut fra klassisk markedsføringsteknikk når det kommer til sluttbrukere: Finn ut hva de ønsker av sluttproduktet, så tidlig som mulig, og ikke med for mange føringer. Kanskje ikke å kalle dem det forslitte «fokusgrupper», men i alle fall være sikker på at produktet er i samsvar med interesser og forventninger. Av og til er det også en fordel når man går over i implementeringsfasen at brukerne faktisk har en type eierforhold til det som skal tas i bruk.

Det kan bety at du må åpne opp for å vise temmelig røffe skisser eller programvare med åpenbare mangler. Det er et mindre problem enn at brukerne hater sluttproduktet, og fyller implementeringshjulene med kjepper senere.

Ineffektiv praksis 8: Kjøpe seg ut av utvikling

Det finnes ofte programvare der ute som allerede gjør noe av det som er ønsket i prosjektet. Det finnes ofte gode grunner for å velge noen slike, og gjøre de nødvendige tilpassingene i oppsett og organisasjon for å ta kommersiell programvare i bruk. Men det er også helt mulig, om enn utrolig, å kjøpe seg hele pakka fra Oracle eller for eksempel IBM WebSphere og fortsatt være i stand til ikke å kunne levere noe til sluttkunden.

Det hele bunner i at det er grenser for hvor mye et utviklermiljø kan absorbere og ta i bruk for tilpassing før kompleksiteten overvelder og kveler alt håp om å levere et brukbart resultat. Is i magan og ikke glemme at en snarvei ikke alltid er den raskeste veien.

Ineffektiv praksis 9: Skrive trivia-koden selv

Det finnes av og til gode grunner å skrive egne buffer-rutiner, database, oppgavekøer, trådgeneratorer eller transaksjonskontroll. For eksempel fordi det er blant hovedproduktene i bedriften man jobber. Dersom det ikke er det, er det som regel bortkastet tid, selv om du klynger deg til redningslinen at «du veit hva du gjør». Som regel er det mengder av kvalitetssikret kode som fikser disse basalfunksjoner – de kan sikkert bedres, men hvorfor bruke tid på skrive ny kode og kvalitetssikre det, når denne tiden kan brukes til å skrive fantastisk kode som kunden ønsker?

Ineffektiv praksis 10: Skriv kode rett til databasekontrollen

Objektorientert tilordning av relasjonsdatabase-systemer (ORM-systemer) er en munnfull i seg selv, og det kan være fristende å hoppe over dette verktøyet.

Å skrive alt direkte mot administrasjonskontrollen til relasjonsdatabasen, om det nå er JDBC eller OleDB, kan virke kjapt og effektivt. Rent bortsett fra at det kan gjøre oppgaven med å gjennomgå og fikse koden usedvanlig kinkig. Den lille omveien gjør det enklere å levere kvalitet.

Det er fortsatt det det handler om.