Hvordan jobbe raskt, men godt

(Jeg ble inspirert av OLORM-en til Lars til å skrive om godt håndtverk)

Jeg har nettopp jobbet tre uker intensivt hos en kunde. De har mange ønsker og lite penger (og dermed lite tid). Jeg ville så gjerne at de skal få så mye som mulig ut av tiden min, men samtidig vil jeg etterlate meg en kodebase som er slik at neste utvikler som kommer inn i prosjektet også har mulighet til å gjøre det samme. Her er noen tanker om hvordan dette er mulig, og hvorfor jeg tror disse tre ukene ble en suksess.

Ha full kontroll på verktøyene dine

Innimellom trenger man å lære nye ting, men denne typen prosjekter er ikke stedet for å lære nye verktøy. Her velger jeg verktøyene som sitter så støpt i fingrene at jeg kan jobbe nesten uten å tenke.

Korte kommunikasjonskanaler

En av grunnene til at disse tre ukene ble en suksess, var at alle som var involvert i prosjektet satt i samme rom, og vi kunne avbryte hverandre. Den enkleste måten å få ting til å dra ut er å legge inn flere timers (eller dagers) kommunikasjonsdelay.

Det raskeste er å ikke gjøre noe

Når den som skal utvikle, den som skal tegne og den som skal bestemme outcome sitter i samme rom, er det mulig å ta noen snarveier allerede før vi begynner å kode. Flere ganger i løpet av disse tre ukene endret vi features mens de var på tegnebrettet slik at de fikk samme outcome, men er enklere å implementere.

Ikke ta snarveier når det kommer til kodekvalitet

Det er mye å si om kodekvalitet, og hvordan man oppnår det. Det får bli en annen post. Men når man jobber på denne måten er man også ansvarlig for at de som tar over etter deg (som ofte er deg selv) også klarer jobbe raskt og effektivt. Ikke stjel fra fremtiden.

Effektiv testing kan ofte være raskere enn å ikke skrive tester. Testing kan gjerne gjøre at du får raskere iterasjoner. Men det krever at du har full kontroll på verktøyene dine.

Tenk enkelt

Ikke bruk tiden på store refaktoreringer. Har den forrige utvikleren stylet koden på en måte du er uenig med, sett til side uenigheten for en stund og fortsett i den forrige utvikleren sin stil. Ikke skriv om hvordan data lastes eller gjør store endringer i arkitekturen. Det kan hende det trengs, men disse tre ukene mens du har oppmerksomeheten til hele resten av teamet er ikke tiden for det.

Etterord

Jeg brøt sannsynligvis alle disse punktene på et eller annet tidspunkt i løpet av ukene, verden er uperfekt og ting går ikke alltid som man vil. Ikke ta noens ord for fasit, men bruk mine tanker til å skape dine egne preferanser for hvordan du velger å jobbe.