Viktig kod ska vara vacker, pytteliten och i kontroll. Allt annat är slöseri med pengar. För mig är det så självklart och internaliserat att jag glömmer att inte alla ser det så här. Om man diskuterar med någon och man har väldigt olika verklighetsuppfattning, då är det svårt att få kvalitet i diskussionen. Båda blir förbryllade och sedan – inget mer. Det slog mig nyligen att många lite schablonartat håller med om att låg programkvalitet är dyrt, men inte tycker eller tror så på djupet.

Låt oss titta på de båda olika verkligheterna (kurvorna) som vi kan välja mellan. För många är det en naturlag att mjukvara ruttnar över tid och ganska snabbt blir extremt kostsam att göra ändringar i.

Boehms kurva (från boken Software Engineering Economics) säger att kostnaden att rätta ett fel stiger exponentiellt över tiden i ett projekt. Man kan nog tolka det som att kurvan till och med fortsätter att stiga efter att första versionen har gått i produktion så att ändringar bara bli dyrare och dyrare. Alla beslut måste alltså tas väldigt tidigt i livscykeln för att inte kosta galet mycket.

Naturligtvis måste det inte vara så här. Becks kurva (från boken Extreme Programming Explained) visar hur det kan vara, det vill säga att kostnaden inte växer exponentiellt utan planar ut.

Det är alltså här som det kommer in hur vacker koden är, hur stor den är och om den är i kontroll. För att åstadkomma den andra kurvan ställs mycket höga krav på mjukvarans skick och att den fortlöpande städas, designas om, har bra automatiska tester och automatiserad driftsättning. En kombination av en mängd väl utförda åtgärder leder till att programmet blir ändringsbart. Verksamhetens värde av det är naturligtvis potentiellt mycket stort.

Kanske ovanstående skillnad i trosuppfattning är anledningen till en del, enligt dig, dumma beslut i din närhet? Men när man har insett hur det förhåller sig är det helt plötsligt inte så konstigt längre. Därmed inte sagt att du håller med om besluten förstås, men när du förstår var personen kommer ifrån så är det åtminstone möjligt att förstå varför personen gjorde valet ifråga.

Om du förresten anser att ni är noggranna när ni utvecklar, men att ni ändå drabbas av den första kurvan, är det nog dessvärre så att koden inte är så superbra trots allt.

För att sammanfatta: om mjukvaran är ändringsbar utan dramatiska kostnader även senare i livscykeln förändrar det allt om hur man tänker kring programutveckling.

Tyvärr finns det en hake. Den flacka kurvan är mycket svårare att uppnå. Möjligt, ja. Men något att vara ödmjuk inför. Hur som helst, det börjar med ett val och jag återkommer i en kommande krönika till hur det kan genomföras.

Har du bestämt dig för vilken kurva du vill ha?