Den gamla sanningen ”if it ain’t broke, don’t fix it” har på senare år mjukats upp en del i takt med att branschen så sakteliga blivit positivt inställd till att kontinuerligt göra om design av mjukvara. Jag anser att man ofta bör gå längre än vad som är brukligt.

Många är alltför rädda för att kasta och skriva om. Långsamt daltande med något riktigt dåligt är sällan rätt medicin. Ibland, eller snarare ganska ofta, så är det rätta att kasta och göra om.

Vid många tillfällen genom åren har jag dragit mig för radikala omskrivningar och haft regelrätt ångest över det hela. När jag väl bestämt mig för att sätta i gång arbetet upptäckte jag att det dels inte alls var lika plågsamt som jag förväntat mig, dels att resultatet till och med blev bättre än jag hoppats.

Jag antar att evolutionen har värdesatt att man inte ska göra om allt varje dag. Men mjukvara behöver inte, och ska inte, vara som allt vi har påverkats av i evolutionen. Troligen minskar rädslan och dramatiken en smula varje gång vi gör det radikala med framgång och det blir ett helt naturligt arbetssätt i vardagen.

Ofta tycker jag att man kommer till en situation och tror att man ska göra en serie refaktoreringsmanövrar för att få det hela dit man vill, men det som händer är att man ganska snabbt ser att det i stället bör vara radikalt annorlunda. De där 30 raderna som skulle transformeras kastas och man skriver två nya. Vips så har man en mycket enklare snutt att förstå och som typiskt exekverar snabbare.

Det är förstås inte alltid odramatiskt att ta beslutet, speciellt inte om det handlar om stora saker. Det vore kul att veta hur tankarna gick för Bill Joy inför arbetet när han (åtminstone enligt hörsägen) skrev om Unix och Java. Det är väl hur som helst rätt svårt att säga emot att de blev framgångsrika. Och visst har du många gånger sett att din andra version blir bättre?

Hur går man till väga för att ta beslutet? Typiskt så har man en drivkraft för att genomföra ändringen och man gör en analys och värdering. Analysen har förstås lämpligen praktiska moment, att göra är ett bra sätt att tänka. Det kan ta sekunder i enkla fall, dagar i andra fall.

Formeln för att värdera de olika alternativen är:

alternativets lönsamhet = tillfört värde – kostnad – risk

Svaret blir alltså lönsamheten för alternativet ifråga och det alternativ med högst lönsamhet vinner.

Enligt min erfarenhet är teknisk excellens i kodbasen alltid mest lönsamt för viktiga program som behöver kunna förändras.

Sluta med daltandet, världen är föränderlig, gör om och gör bra! Det enda som är konstant är förändring som Herakleitos lär ha sagt.