Tar varje liten ändring i din applikation tre veckor? Här är varför, och vad du kan göra åt det

Du behöver bara ett nytt fält i ett formulär. Eller en kolumn till i en rapport. Teamet säger: tre veckor. Du frågar varför och får en förklaring du inte förstår, men som låter allvarlig.

Och du minns att det var annorlunda förr. Första året kom nya saker på några dagar. Teamet har inte blivit sämre. Det har systemet de arbetar i.

Varför det händer: teknisk skuld

Tänk dig ett hus som har byggts ut i tio år utan plan. Varje gång har någon dragit en kabel genom en vägg i all hast, eftersom det gick snabbast. I dag måste du bryta igenom tre väggar för att flytta ett enda uttag, och hoppas att du inte kapade något i rummet bredvid.

Inom mjukvara kallas det teknisk skuld, och den beter sig precis som en skuld: varje gång något görs i all hast tar du ett lån. Räntan betalas på varje ändring som följer. Efter några år är räntan större än själva lånet, och all utveckling går till amorteringar.

I en applikation ser det ut så här:

• Allt hänger ihop med allt. En ändring på ett ställe förstör något på ett annat, så varje ändring måste kontrolleras för hand överallt.
• Det finns inga automatiska tester. Varje ändring innebär att hela applikationen testas för hand, och rädslan för att förstöra något gör att allt går långsammare.
• Samma logik är kopierad på tio ställen. En ändring måste göras tio gånger, och ett ställe glöms alltid bort.
• Releaser görs för hand och är riskabla. Därför är de sällsynta, kommer i stora klumpar, och alla håller tummarna.
• Bara en person kan en del av systemet. Allt som rör den delen får vänta på den personen.
• Tekniken är föråldrad. En gammal version av .NET och bibliotek som inte går att uppgradera utan att allt annat faller sönder.

Så ser du att det är ditt problem också

Du behöver inte läsa kod. Det räcker att hålla utkik efter det här:

• uppskattningarna för liknande uppgifter blir hela tiden större
• teamet säger ”det där rör vi inte” om vissa delar av applikationen
• något går sönder efter varje ny version
• nya utvecklare behöver månader innan de kan arbeta självständigt
• svaret på ”varför tar det så lång tid” är alltid ”det är komplicerat”

Om du känner igen tre eller fler är problemet inte människorna, utan systemet.

Det som inte hjälper

Att anställa fler. Fler personer i ett trassligt system betyder fler personer som förstör varandras arbete. Fred Brooks skrev det redan 1975: att lägga till folk i ett försenat mjukvaruprojekt gör det ännu mer försenat. Och att hitta en bra senior utvecklare tar ändå månader.

Att sätta press på teamet. Ett team under press tar ännu fler genvägar, och varje genväg är ett nytt lån. Skulden växer snabbare.

Att skriva om allt från grunden. Det låter som en lösning, men det innebär ett eller två år utan nya funktioner, och att du kastar bort allt det gamla systemet gör bra. Det är sällan rätt första beslut, som vi också skrev här.

Det som hjälper

Skulden betalas inte av på en gång, utan i en klok ordning:

1. NulägeVart tiden tar vägen
2. FlaskhalsarDet som ändras oftast
3. SkyddsnätTester och automatiska releaser
4. Efter handVarje ändring lämnar koden bättre

1. Nuläge. En oberoende genomgång av koden och av hur en ändring tar sig från beställning till produktion. Exakt vart tar tiden vägen: att skriva kod, att testa, att vänta eller att rätta det som gick sönder på vägen?
2. Flaskhalsar. Allt behöver inte åtgärdas. Delar som ingen rör kan få förbli fula. Det som ändras oftast tas om hand först, eftersom det är där räntan betalas varje vecka.
3. Skyddsnät. Automatiska tester runt de viktigaste delarna, och releaser med ett klick. När ingen i teamet är rädd för ändringar går ändringarna snabbare av sig själva.
4. Efter hand. Varje ny funktion lämnar koden den rör lite bättre än den var. Utvecklingen stannar inte, och skulden betalas av i omgångar.

De första förbättringarna syns oftast inom några veckor, inte år, och utan att utvecklingen stannar. Det bästa måttet är enkelt: hur lång tid en typisk ändring tar, från beställning till produktion, före och efter.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien, och att reda upp system som med åren har blivit långsamma att utveckla är något av det vi gör oftast.

Vi börjar med en genomgång av koden och processen, och du får en lista över flaskhalsar rangordnade efter hur mycket de kostar dig. Sedan åtgärdar vi dem tillsammans med ditt team eller i dess ställe, det som passar dig bäst. Det första steget är ett kostnadsfritt samtal på 30 minuter där vi går igenom hur en typisk ändring ser ut hos dig.