TestFirst+JUnit:

Å ena sidan: Puke kräver agilitet, och agilitet kräver refaktorering. Refaktorering kräver testbarhet. Ju större testbarhet, desto billigare och bättre refaktorering. TestFirst och JUnit (och CI-motorer och allt), ger större testbarhet.

Å andra sidan: TestFirst ger en spec som är direkt testbar. Du vet direkt om koden följer specen eller ej. Men det ger ingenting i fråga om att säkerställa att man kommit fram till RÄTT SPEC! Själva utvecklingens grundfråga: VAD ska vi koda? står kvar.

Alltid lättare att införa (och motivera) en teknisk skuld än vara den som får betala skulden.
Har erfarenhet av båda sidor.
Men som Per skriver så om det är tveksamt att något behövs så behövs det nog inte, åtminstone inte nu och inom en snar framtid.
Utveckla inte för långt in i framtiden då när framtiden är här så är den inte vad man trodde den skulle bli då (hängde ni med? nästan inte ens jag själv gör det).

När den här problematiken tacklas från affärssidan heter det inte ”Puke”, utan ”Business Alignment”, ett område som har problemställningen ”Hur få IT att gå i takt med resten av organisationen”?

Puke är en del av mitt svar på den frågan.

@Per: Instämmer till 100 % i ”Puke [lyfter fram] att man skall tänka efter ordentligt om ett visst pattern verkligen [är] värt det rent ekonomiskt”.

@Ola: Du har lyft upp ett bra ämne som vi alla tampas med dagligen. Att göra teknisk skuld synlig för produktägaren måste bli lika självklart som att använda SCM. Att få produktägaren att kunna väga teknisk skuld vs ”annat” är målet och ett drömscenario – eller finns sådan beställarorganisation i närheten?

Det jag tycker lyfts fram bra med Puke är att man skall tänka efter ordentligt om ett visst pattern verkligen gör systemet bättre och om det är värt det rent ekonomiskt.

*If in doubt leave it out* funkar bra att följa när det kommer till designval. Det är väldigt lätt att man försöker stödja hela allt i universum och helt plötsligt blir det för komplext för att användas.

Problemet som jag ser det är att de (utvecklarna) som skapar teknisk skuld med beställarnas goda minne är att det sällan samma personer som är där när det är dags (måste) betalas tillbaka för att systemet inte ska braka samman och fortfarande kunna vidareutvecklas.
Kostnaden för tekniska skulden ökar oftast ju längre man väntar.
Ibland kan man avskriva skulden genom att man klarar sig tills det är dags att lägga ner av andra skäl.
Ibland så måste en totalomskrivning göra med mindre teknisk skuld och kan göras parallellt medan det gamla lever.

Håller fullständigt med om att av ekonomiska skäl finns anledning att skapa denna skuld för att huvudtaget komma upp på banan.
Finns otal historier om system som man försökt göra ”perfekta” från början som har lagts ner innan de ens levererats pga att kostnaderna skenat.

Även om produktägare blivit informerade och accepterat att skulden måste regleras inom tid så glömmer de ofta bort det tills det är dags.
Men om man bara har en beställare som betalar så kanske man hoppar när denne säger till när alternativen tryter.

Om vi ser att våra beslut har affärsmässiga implikationer måste vi kommunicera dessa.

Det låter som om du beskriver en ignorant beställare. Acceptera inte det.

Det stämmer. Kostnaden för en teknisk skuld är en spekulation. Man gissar och tar en chansning, eftersom man vet att man inte kan kontrollera alla variabler.

Men detsamma gäller ju intäktsmöjligheten. Den är också en potential. Man kan göra sitt bästa för att öka chansen till god intäkt, men i slutändan är även det en spekulation.

All affärsverksamhet är från början en spekulation i risker och chanser. Det är därför jag argumenterar för att beslutet att ta en teknisk skuld i slutändan ligger hos den som har ett affärsansvar för produkten.

Att fatta egenmäktiga beslut är något vi utvecklare måste göra hela tiden. Vem bad tex mig att använda EJB2 eller Spring. Vi har rätt stort anvsvar över den totala kostnaden för ett system beroende på vad vi som utvecklare väljer för lösningar. Så jag ser inga konstigheter i detta.

Det viktiga är att man hela tiden jobbar för produkten och företagets bästa. Det är inte alltid lätt att avgöra vad det är men vi utvecklare har ett stort ansvar där eftersom vi är dom enda som förstår mjukvaran på företaget.

Frågan är vem som skall kunna avgöra hur stor kostnaden är av en teknisk skuld. En teknisk skuld är ju ofta av den typen som potentiellt kan bli ett problem för att det leder till ostabilitet eller att det försämrar koden som gör att man ”kanske” måste skriva om vissa delar eller hela systemet på lång sikt. Det går inte att räkna om något sådant i pengar. Det är svårt till omöjligt att beräkna den totala kostnaden av en teknisk skuld.

Det jag däremot tycker har funkat bra som jag varit med om är att ha en slot av utvevklingstiden varje sprint till att jobba med teknisk skuldavskrivning och på så sätt så behöver man inte prioritera feature mot en teknisk skuld med andra ord så jämför man mer äpplen med äpplen.

I så fall fattar du egenmäktigt beslutet att organisationen ska undvika att ta vissa affärsrisker.

Du ska inte väga en teknisk skuld mot en feature, om du är utvecklare.

Det är produktägaren som ska göra den avvägningen. Det är nämligen en affärsmässig avvägning, eftersom featuren potentiellt sett innebär en intäkt och skulden innebär en kostnad.

Jag är ändå inne på den linjen att man skall försöka göra allt för att förhindra att det upstår. Det är ju ofta man själv som står för tidsestimeringen och visar det sig att den inte håller och man har frågat efter mer tid men blivit nekad då får man ju ta en teknisk skuld och dokumentera det men jag tycker att man bör undvika det så långt som det är möjligt.

Gärna under en egen ärendekategori (”technical debt” eller ”ugly hack” eller så).

Då har du ett kvantifierat mått på hur kodbasen degenererar.

Men vilket kvantifierbart sätt som helst är bra. Vinsten ligger i synliggörandet. I och med synliggörandet görs det till produktägarens problem, och produktägaren får då själv fundera över vilken sorts vidareutbildning som krävs.

Den andra delen av frågan rör vilken sorts utbildning produktägare (och resten av organisationen) behöver i största allmänhet. Där säger jag: arkitektur. Ingen utanför utvecklarnas krets behöver kunna koda. Men alla måste ha en bild av systemets centrala komponenter och deras respektive ansvarsområde, och ett ungefärligt hum om hur dessa komponenter samarbetar.

Precis som utvecklarna behöver ett hum om hur säljprocess fungerar, och alla behöver grundkunskaper i företagsekonomi.

Jag pratar om kunskaper motsvarande en halv universitetstermin, typ introduktionskursen. Inget dramatiskt med andra ord, utan ett översiktligt införande i den grundläggande terminologin.

Sen handlar det bara om att kalibrera fram rätt viktning…