Ikke gå på en smell med teknisk gjeld!

Om forfatterne

Abonner

RSS feed

Sist publisert

Arkiv

Søk i bloggen

Capgemini på Twitter

Følg Capgemini på Twitter

« La de ansatte bruke Facebook på jobb | Teknologiblogg | Hjemmesnekrede rammeverk »

Jeg har jobbet med å utvikle programvare i 8 år. I løpet av denne tiden har jeg erfart at de samme problemstillingene går igjen og igjen – på tvers av prosjekter. Den vanligste gjengangeren er at det er kort tid til leveranse, og alt for mye å gjøre. Da må vi, prosjektgruppen, ta stilling til om vi skal levere en mindre god løsning for å rekke tidsfristen – ”quick and dirty”, eller om vi skal levere en gjennomarbeidet løsning, og gå over tidsfristen.

Dilemmaet er som følger; velger vi ”quick and dirty”, rekker vi å levere i tide, men det går på bekostning av design og kvalitet – noe som fører til at kildekoden blir vanskelig å vedlikeholde. Dersom vi velger det motsatte, rekker vi ikke å levere i tide, men til gjengjeld leverer vi en bedre løsning. Noe som fører til bra design og vedlikeholdbar kildekode.

Jeg er helt sikker på at også du har, en eller annen gang, støtt på denne problemstillingen. Kanskje som programmerer, prosjektleder eller kanskje du til og med har sittet på kunden sin side av bordet.

Så hva skal vi velge? ”Quick and dirty” eller en tidkrevende løsning? Slik jeg ser det, er ikke det ene valget alltid bedre enn det andre, men det e viktig å være klar over konsekvensene av valget man tar – spesielt ”quick and dirty”.

Ward Cunningham har kommet frem til en passende metafor:

“I coined the debt metaphor to explain the refactoring that we were doing on the WyCash product. This was an early product in Digitalk Smalltalk, and it was important to me that we accumulated the learnings we did about the application over time by modifying the program to look as if we are normally doing all along and to look as if it'd been easy to do in Smalltalk.

The explanation I gave to my boss, this was financial software, was a financial analogy, I called it debt metaphor.

And that said that if we fail to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement which was like paying interest on a loan.“ – Ward Cunningham

I hans metafor betyr en ”quick and dirty” løsning det samme som et banklån i finansverden. Et lån gir deg kjøpekraft, som gjør at du kan handle uten penger. Som for eksempel er en vanlig situasjon for unge mennesker som kjøper bolig for første gang. Ulempen med et slikt lån er det må betales tilbake – med renter. Hvis ditt prosjekt går for en slik løsning, må dere regne med å bruke tid på å betjene teknisk gjeld. Altså, dere må regne med å bruke tid på å vedlikeholde eksisterende kildekode i stedet for å utvikle ny funksjonalitet.

Jeg vil at du skal tenke på denne metaforen neste gang du må velge mellom ”quick and dirty” eller en mer gjennomarbeidet løsning. I mange sammenhenger er det akseptabelt å ta opp lån, dersom det gjøres i kontrollerte former. Og akkurat som i den virkelige verden, så er det ikke særlig lurt å ta opp et større lån enn man klarer å betjene.

Om du velger ”quick and dirty”, kan jeg anbefale deg å sette opp en nedbetalingsplan. Denne planen vil synliggjøre gjelden som du skal nedbetale med dine likvide midler. Dersom prosjektet ditt kjører en metodikk som for eksempel SCRUM, så kan det være lurt å legge inn arbeidsoppgaver i de neste sprintene (iterasjonene), for å betjene gjelden.

Dersom ”time to market” er viktig, så er det helt legitimt å ta opp lån, men husk og ikke ta opp for mye lån. Ha en klar plan for hvordan det skal tilbakebetales.

Jeg vet at det er vanskelig å måle produktivitet, men jeg tror at et prosjekt med høy teknisk gjeld blir mindre produktiv. Og hvis du aldri nedbetaler den tekniske gjelden, vil prosjektet ditt før eller siden grunnstøte. Prosjektet behøver ikke være gjeldsfritt, men om du tar opp lån, så gjør du gjør det med omhu!

Publisert av Gøran Hansen den 13 Mai 2009 i smidig

Kommentarer

# den May 14, 2009 9:54 AM, sa Arvid Karlsen :

Hei,

Denne kommentaren var veldig informativ og interessant. Metaforen banklån er relevant. Jeg vil likevel dra metaforen litt lenger.

Et prosjekt oppstår som følge av kundekrav. Man blir enige om produkt, pris og leveringstidspunkt. Skal man bruke metaforen, er banklånet allerede etablert. Man skylder kunden et produkt som skal leveres til en bestemt tid til en bestemt pris. Dette mener jeg er den tekniske gjelden.

Om man ikke kan levere enten et godt produkt eller til riktig tid, kan dette sammenlignes med ikke å klare avdrag og renter. Løsningen må da bli å refinansiere lånet ved å ta kontakt med sine kreditorer. Man kan bl.a. forsøke å forlenge nedbetalingstiden, ved å betale tilbake mindre beløp pr termin.

Mitt poeng er at "banklånet" er en avtale mellom kunde og leverandør om leveranse. Kunden skal betale for et produkt. Leverandøren skal levere et produkt til en gitt tidsfrist.

Leveransen er summen av løfter fra salg, utvikling, support og annen involvert kompetanse. Disse løftene må være realistiske. Loves det leveranse innen 12 mnd, forventes det at leveransen skjer innen 12 mnd. Man må derfor ha et realistisk syn på sin "nedbetalingsevne".

Sagt på en annen måte: Prosjektet består av oppgaver og produkter som skal leveres. Dette er nedbetalingen av den tekniske gjelden. Hvis man ser at man ikke klarer å betjene gjelden har man kanskje overvurdert seg sin egen produktivitet.

Man bør altså velge sine prosjekter med mer omhu.

# den May 15, 2009 9:28 AM, sa Espen Lilleengen :

Interessant, men når du forhandler om et oppdrag så må du jo ha en plan. Den bør du ha en god +margin på når det gjelder tid. Har du ikke det, havner du mest sannsynlig i quick and dirty-situasjonen. Prosjekter skal jo ikke bestå av flaks. Du skal lede kunden til å godta den beste løsningen. klarer du ikke det, er du ikke flink nok i det du gjør. Du kan også se bort fra dette, og fortsette og tro på flaks og være kynisk.

# den May 15, 2009 10:56 AM, sa Gøran Hansen :

Hei Arvid!

Tusen takk for at du tok deg tid til å kommentere denne posten!:)

Jeg synes du har er en spennende vinkling på metaforen. Jeg ser helt klart at den kan brukes på flere nivå!

Helt enig i at man bør velge sine prosjekter med omhu. Prosjekter er krevende – det handler om å ha de rette ressursene og en god metodikk. Dersom man overvurderer seg selv, kan man havne i en situasjon med alt for høy teknisk gjeld. Utfordringen er å oppdage dette tidlig, slik at man kan gjøre nødvendige grep for å få kontroll på situasjonen. for eksempel kan man forsøke å refinansiere lånet – slik du foreslo!

Men det kan også være en ufordring å velge prosjekter med omhu. For eksempel er det viktig å forstå kompleksiteten av leveransen for å kunne gjøre et fornuftig estimat. Min erfaring; det er først når man har utviklet kunnskap om domenet man ser kompleksiteten av leveransen. Dette gjør det ufordrende når man skal vurdere sin egen nedbetalingsevne.

Meget bra kommentar! Dette satt i gang mange tankeprosesser i hodet mitt.

Gøran

# den May 15, 2009 11:29 AM, sa Gøran Hansen :

Hei Espen!

Takk for at du tok deg tiden til å legge igjen en kommentar!

Jeg kunne ikke vært mer enig med deg! Selvfølgelig skal man lede kunden til å ta de beste avgjørelsene.
Spørsmålet er; hva er den beste avgjørelsen? Dersom ”time to market” er viktig for kunden, er det kanskje nødvendig å ta opp teknisk gjeld for å levere så fort som mulig. Det er da viktig å redegjøre for konsekvensene av dette valget ovenfor kunden.

Dersom stabilitet og endringsdyktighet er viktige egenskaper for programvaren som utvikles, er det ekstra viktig å bekjempe teknisk gjeld. Det er også da viktig å redegjøre for konsekvensene slik at kunden forstår hvorfor det tar lengre tid. Dette bør også inngå i planen som du nevnte.

Programvareutvikling er en krevende disiplin og må ikke undervurderes. Gjennomfører man et prosjekt basert på tilfeldigheter og flaks, er man som du sa, ikke flink nok i det man gjør. Dette er svært uheldig, og man vil da neppe få tillit hos kunden.

Gøran

# den May 15, 2009 2:37 PM, sa Torgeir Kruke :

Hei

Jeg får en assosiasjon når jeg ser kommentarene fra Arvid: "Man bør altså velge sine prosjekter med mer omhu" og Espen: "når du forhandler om et oppdrag så må du jo ha en plan. Den bør du ha en god +margin på når det gjelder tid."

Veldig ofte legger kundene svært mye vekt på pris, noe som ofte fører til at den som har underestimert prosjektet får oppdraget. Dette kalles "winners curse" fordi den som vinner oppdraget lett havner i gjeld - både teknisk og merkantilt!
Bankene er nøye med å vurdere kundenes betalingsevne før de deler ut lån. Jeg skulle ønske alle som kjøper systemutviklingstjenester var like gode til å vurdere leverandørenes leveringsevne - og legge inn den nødvendige tiden til å levere med kvalitet og unngå den tekniske gjeldsfella.

Torgeir

# den May 15, 2009 4:04 PM, sa Børge Hansen :

Jeg er enig i at dette er en korrekt observasjon og en metafor som kan brukes.

Brannfakkel: Jeg synes du fokuserer litt ensidig.

Ofte stiller man spørsmålet; "Hva er den beste og mest korrekte arkitekturen for dette prosjektet?"
Mens kanskje like ofte kunne man spurt: "Hva er den minste arkitekturen som løser mitt problem? Og kanskje enda viktigere: Hvordan/Hvorfor er de to forskjellig?

Med "minste" menes antall moduler, linjer kode, conf filer mm. Ofte har vi en tendens til å overdesigne og generalisere, mens en rett frem løsning kunne vært god nok.

Og med de rette verktøyene og metodene er det mulig å raskt gjøre en redesign/refactoring. Altså man finner raskere måter å "betale ned gjelden på".

Kjør debatt :-)

# den May 18, 2009 2:16 PM, sa Joachim Nilsson :

Det som är skillnaden mellan en teknisk skuld och t.ex. ett billån är att man blir av med den tekniska skulden ifall man köper ett nytt system. Synd att inte samma sak gäller bilar...

# den May 19, 2009 3:58 PM, sa Gøran Hansen :

@Joachim

Haha :D

# den May 19, 2009 4:19 PM, sa Gøran Hansen :

@Torgeir

Helt enig! De som kjøper systemutviklingstjenester må være mer kritisk til valg av leverandør. Korrekt meg hvis jeg tar feil, men jeg forestiller meg at det kan være vanskelig å vurdere en leverandørs leveringsevne? Bankene vurderer kundenes betalingsevne basert på kredittvurdering, likning og lønnslipper. Finnes det en standardisert evalueringsform for leverandører av systemutviklingstjenester?

Og jeg er helt enig i at de som underpriser seg vil være presset på tid. Da er dessverre sannsynligheten stor for at de vil nedprioritere teknisk gjeld…

Takk for at du tok deg tiden til å legge igjen en kommentar:)

# den May 19, 2009 4:52 PM, sa Gøran Hansen :

@Børge

Hvorfor skal vi gjøre det enkelt, når vi kan gjøre det vanskelig?:D

Jeg er tilhenger av KISS (Keep it Simple, Stupid) og YAGNI (You Ain’t Gona Need It) prinsippene, og derfor er jeg helt enig med deg!

Ofte ender vi opp med å skyte spurv med kanon – hvorfor? Fordi det er vanskelig å komme opp med en enkel løsning. Spørsmålet er da; hvorfor velger vi da overgeneralisert design fremfor minimalistisk design?

Du nevner at man bør se på den beste, og den minste arkitekturen for løsningen, og deretter ta en beslutning basert på behov - jeg er helt enig! For hvis man ikke gjør dette, har man allerede opparbeidet seg teknisk gjeld!

Du har rett, jeg var ensidig i posten min. Man kan levere en gjennomarbeidet løsning i tide, men utfordringen er å finne frem til den løsningen. På grunn av tidspress har jeg sett en tendens til at den første og beste løsningen velges. Hva skal til for at det velges en rasjonell løsning i slike situasjoner? – erfaring, domenekunnskap, kreativitet?

Veldig, veldig bra debatt!:)

# den May 20, 2009 1:06 PM, sa Ole Gunnar Borstad :

Jeg mener det er to forskjellige begreper Gøran Hansen beskriver om i bloggen og den formen for gjeld Arvid Karlsen beskriver i kommentaren.

Gjelden slik Arvid beskriver den, er det som blir beskrevet i en kontrakt mellom kunde og leverandør. "Lever denne funksjonaliteten til gitt tidspunkt og pris". Dette er en veldig synlig gjeld, og mislighold vil få konsekvenser veldig tidlig, f.eks i form av redusert timepris, kansellering osv. Det skumle er at man kan fint levere et prosjekt og innfri denne gjelden, men LIKEVEL ha teknisk gjeld slik den er definert i Gørans opprinnelige innlegg.

Et prosjekt/produkt kan se sunt ut på overflaten, men med tid vil man merke hvordan den tekniske gjelden gjør produktet uhåndterlig. Da er det ofte for sent fordi lav kodekvalitet og høy kobling gjør at endringer og utvidelser rett og slett ikke betaler seg lengre.

Et problem med denne tekniske gjelden er at det er vanskelig å kvantifisere en verdien av å unngå teknisk gjeld. Hva er ROI ved å implementere en modul med høy kvalitet ift. raskeste løsning som fungerer? Vi vet ikke svaret på dette før langt fram i tid, og da har vi allerede bygget oss opp en stor teknisk gjeld fordi vi har blitt fristet til å ta kjappe løsninger underveis.

Håper poenget mitt kom fram. Som utvikler ser jeg og må leve med den teknisk gjeld hver dag. Jeg håper at vi utviklere blir flinkere til å øke synligheten av teknisk gjeld slik at de med beslutningsmyndighet har bedre grunner for å prioritere kodekvalitet.

Legg inn en kommentar

Commenting Policy