Bedre nå slår best senere

En veldig sann blogpost, som samtidig kanskje får ting til å høres enklere ut enn de er: Bedre nå slår best senere.

Jeg har vel knapt vært på ett prosjekt hvor vi ikke har utsatt å gjøre en liten forbedring vi kunne gjort i dag, fordi vi ser at vi kan gjøre en større forbdedring i morgen som inkluderer eller overflødiggjør den lille forbedringen vi kunne gjort i dag. Og da er det jo bortkastet tid å gjøre dagens forbedring. Eller?

Eksempel:

- Ja, variabelnavnene i denne klassen er helt på bærtur, men vi må gjøre en opprydning i flere variabelnavn og bør se alt under ett.

- Ja, dette brukergrensesnittet er helt ubrukelig, men vi skal gjøre en større endring i funksjonaliteten uansett, så da vil vi lage et nytt grensesnitt.

- Ja, denne koden er helt spaghetti, men i stedet for å forsøke å forbedre den litt nå, bør vi kaste den og skrive den på nytt.

- Ja, vi kan løse problemet for kundene nå med denne lille justeringen, men skal vi først implementere noe slikt må vi gjøre det 100% og da må vi også ta med ... (fyll inn det som passer)

Et viktig kontrollspørsmål når slike innvendinger kommer og vil stoppe en forbedring, er: Når er det planlagt å gjøre denne store forbedringen? Hvis det ikke finnes et konkret svar på dette spørsmålet, bør man virkelig vurdere å gjøre forbedringen nå, og så heller leve med at Den Store Forbedringen en gang i framtiden kanskje overflødiggjør jobben.

Veldig ofte er det ikke snakk om mange timene uansett. I hvert fall ikke for å få til en viss forbedring. Og hvor mye taper vi på å ikke gjøre forbedringen her og nå? Altså bør vi gjøre en kost/nytte-analyse som delvis ser bort i fra at Den Store Forbedringen kommer, og ser på nytten ved å løse problemet med én gang uavhengig av hva vi tror vil skje om noen uker eller måneder.

I realiteten er det selvfølgelig ikke så enkelt. Man vil jo gjerne ofte tro på at den store forbedringen er rett rundt hjørnet og snart, snart vil bli inkludert i en iterasjonsplan. Og dessuten har man kanskje så mange forbedringer man ønsker å gjøre at man uansett må prioritere - og da virker det selvfølgelig fornuftig å nedprioritere de tingene som uansett vil bli håndtert på et senere tidspunkt.

Som en tommelfingerregel tror jeg likevel at bedre nå må slå best senere mye oftere enn det som skjer i praksis.

Clean code: Hvordan kvalitet påvirker produktivitet

Det har blitt sagt før, men det skader aldri å gjenta det: Clean code er alfa og omega for å kunne holde produktiviteten oppe. Derfor bør vi skrive tester før vi koder, derfor bør vi hele tiden refactore og derfor bør vi også parprogrammere. Disse aktivitene, som tilsynelatende gjør oss mindre produktive, øker faktisk produktiviteten - fordi de er med på å sikre den interne kvaliteten på produktene våre.

Ekstern kvalitet (features) kan skjæres ned, for eksempel for å nå en dato. Intern kvalitet må vi aldri ofre.

Se anarcycreek for mer inspirasjon!

Hvorfor smidig feiler - eller?

James Shore har skrevet en artikkel om hvorfor mange smidige team sliter. Han spår at det at mange team mislykkes på tross av at de (hevder at de) jobber smidig, til slutt vil føre til at folk vender ryggen til smidig. Smidig får skylda for problemene, mens det egentlig er utførelsen som er feil. Akkurat det har jo Simon Johnson en litt annen vinkling på. Men det er en interessant artikkel, les den gjerne, der særlig Scrum får mye av skylda for at det er så mange som hevder de driver smidig uten å egentlig gjøre det.

På en måte føler jeg kritikken mot de som forsøker å drive smidig, men ikke får det til 100% blir litt lettvint. For eksempel: "De sier de driver smidig, men de er jo ikke samlokaliserte, så klart at de ikke driver ordentlig smidig, og klart at de vil slite". Ikke alle team har muligheten til å være samlokaliserte. Ikke alle team har en sterk produkteier som er nok tilgjengelig. Ikke alle team behersker alle de tekniske teknikkene i XP. Og så videre.

Det er egentlig ganske selvfølgelig at et team som har alle forutsetninger på plass, slik de er beskrevet i XP eller i James Shore's veldig gode bok om smidig utvikling, vil lykkes. Utfordringen for de aller fleste er å begripe hva som er det ideelle, hvor man avviker fra det ideelle, og så finne ut hva man kan gjøre for å nærme seg det ideelle best mulig. Og siden de fleste av oss har mye å vinne på flere områder gjelder det også å finne ut hva som vil gi mest verdi å endre, og så angripe det området først.

Det må nevnes at jeg synes The Art of Agile Development av James Shore er et ypperlig verktøy for nettopp å forbedre prosessene sine litt etter litt. Og det finnes mange andre gode kilder til kunnskap og inspirasjon i forbindelse med smidig. Det viktigste er at vi hele tiden forsøker å forbedre oss. Hvis vi noen gang når den perfekte prosess er det 100% sikkert en illusjon.

En programmerers bekjennelser

Er du som meg, gremmer du deg av og til over synder du har begått i løpet av karrieren - da du ikke visste bedre eller kanskje handlet mot bedre vitende.

Det er flere av oss - les Jeremy Millers bekjennelser - mens du ler gjenkjennende!

Program manager

Joel Spolsky skriver på bloggen sin om rollen "Program manager", en rolle som var ganske ukjent for meg. Det nærmeste vi har vært, har vært prosjekter der det har deltatt interaksjonsdesignere som har laget funksjonelle spesifikasjoner som utviklerne har tatt utgangspunkt i. Men jeg synes det virker som om Program manager-rollen inneholder mer enn dette.

Kanskje kunne vi hatt nytte av en klarere Program manager-rolle på prosjektene våre?

Suksessprosjekt = Suksessmetode ... eller?

Hvor stor rolle spiller egentlig metoden vi jobber etter for i hvor stor grad vi lykkes med prosjektene? Ganske stor, vil jeg si, hvis jeg ikke sa det ville jo mye av mitt engasjement i smidige metoder være rett og slett bortkastet.

Men vi må heller ikke glemme at metoden ikke er alt - les om MDD og reflekter!

Se lyntalene fra Smidig 2008

Var det noe du ikke fikk med deg? Alle lyntalene fra Smidig 2008 er nå tilgjengelige for dem som vil se!

Alle foredragene.

Mitt foredrag om teknisk gjeld: