Annonsørinnhold:

Derfor er ikke flere utviklere alltid løsningen

Publisert

Det er en utbredt tanke at du kan sette fart på et prosjekt ved å involvere flere utviklere. Men er det egentlig sånn? Vår egen Vladimir Janjušević forklarer deg fordelene og ulempene ved å koble på mange hoder.

Scenarioet er velkjent: Løsningen du ønsker deg, skulle helst vært lansert i går. Du vet at tiden begynner å bli knapp, men denne gangen har du jo et romsligere budsjett. Er det ikke bare å putte på flere utviklere for å få dette i havn ASAP?

– Vi møter denne forventningen ofte. Realiteten er at det gjerne er motsatt. Flere utviklere kan gjøre at prosjektet går tregere, spesielt mot slutten, sier Vladimir.

Jo flere, jo raskere?

Det kan kanskje virke kontraintuitivt, men fenomenet er faktisk så vanlig at det har fått et navn. Brooks’ lov kalles det i utviklermiljøet, og Vladimir forklarer hvorfor det er slik.

«Adding manpower to a late software project makes it later.»

– Brooks’ lov

– Det tar tid å flytte ressurser, justere informasjonsflyten og drive opplæring. I tillegg vil du med flere folk også finne flere bugs. Det er selvsagt bra, men da går det også med mer tid. Du kan alltids bare lansere, lykkelig uvitende om hvilke bugs som finnes, men så fort du vet om dem, må du fikse dem først.

Vladimir oppsummerer det med et sitat av Brooks: «Nine women can’t make a baby in one month.»

– Det er selvsagt naturlig å ønske seg at ting blir ferdig så fort som mulig. Men dårlig tid, uansett hvor mange utviklere du har, vil gå utover kvaliteten. Og det som er billig, kan fort bli dyrt, påpeker Vladimir.

Vil du vite hvordan billig kan bli dyrt? Sjekk Vlad forklare her!

Kan være bedre

Det Brooks’ lov mangler, ifølge Vladimir, er at kvaliteten øker med antall utviklere. For det er selvsagt ikke slik at det alltid er en dårlig idé å ha et stort team.

– Nei, og spesielt i starten er det lurt å være flere. Særlig hvis de er synkronisert og jobber godt sammen. Da får du kickstartet prosjektet, forklarer Vladimir.

Selv er han en stor tilhenger av å være flere hoder, gitt at de jobber sammen fra starten – og har tilstrekkelig med tid.

– Jeg liker å samle mange meninger inn i et prosjekt, og å ha folk å sparre med. Har vi det, og gjennomfører prosjektet i et fornuftig tempo, er det også lettere å gå tilbake senere og videreutvikle løsningen, sier han, og legger til:

– Utfordringen kommer altså når du legger til flere utviklere sent i løpet. Det kan fungere greit hvis du setter dem for eksempel kun til dokumentasjon, men selv det vil bremse og dermed forlenge tiden.

Dette bør du gjøre

Vladimirs beste råd er å spørre om hjelp tidligere. Det er ikke slik at du trenger å gjøre forarbeidet helt alene.

– Vi kan hjelpe deg allerede i planleggingsfasen, og gir deg ressurser og ideer mens vi estimerer. Denne sparringen hjelper å gi prosjektet en stø kurs, sier han.

Han anbefaler alle å ta utgangspunkt i kvaliteten de ønsker. Vil du at noe skal bli virkelig bra, hjelper det ikke å ha et stort budsjett dersom tiden er for knapp.

– Tidspress er det verste for utviklere, og dermed også for sluttproduktet. Vær derfor tidligere ute enn du tror er nødvendig. Da blir resultatet aller best. Dessverre tar ofte folk kontakt når det allerede er litt for sent, sier han og avslutter:

– Noe av det tristeste jeg vet, er fantastiske ideer som hadde fortjent mer tid.