Fordi det ganske enkelt er det bedste software, der nogensinde er udviklet til at løse deres problemer. Fra 70'erne!

Ja, undskyld alle mine udråbstegn, men det er da utrolig interessant, når andre virksomheder kæmper med, at 5-10 år gammelt software er ved at blive Legacy.

Hvad i al verden er det, der gør, at et softwaresystem nogle gange kan fortsætte normal udvikling langt ind i sit voksne liv og længe efter, at man normalt ville kalde det Legacy. Uden større problemer.

Og andre gange kan et 5 år gammelt softwaresystem, der dårligt er kommet ud af sin tumlingetilværelse, blive betegnet som et Legacy-system, som det er umuligt at finde folk, der gider videreudvikle.

Der er selvfølgelig de åbenlyse forklaringer, som alle i et eller andet omfang begynder med teknologien: Den underliggende platform er for gammel. Arkitekturen er for dårlig. Kodekvaliteten er ikke høj nok.

Men... Der er også den skjulte årsag.

Kode er ikke teknologi

Softwares mest basale byggeklods er kildekode.

Men kode er ikke teknologi.

Kode er den tekst, udviklere udtrykker et programs opførsel i. Det er ... tekst. Udtrykt i et sprog ligesom al muligt anden tekst. Vi gemmer det i en database, så vi kan finde det igen, og vi har opfundet avanceret versionsstyring, så vi har styr på, hvem der retter hvad, hvor, hvornår og hvorfor i den samlede base. Men moderne kildekode er - præcis som i 70'erne - tekst.

Kildekode kan grundlæggende ikke blive for gammelt.

Kildekode kan blive komplekst, fordi det er formuleret på en besværlig måde.

Kompleks kildekode er besværlig at vedligeholde, fordi det er besværligt at forstå. Men det er ikke dét, der er den skjulte årsag til Legacy. For der er noget, som gør kildekode endnu sværere at forstå.

Hvad er det, der gør, at det tager nye udviklere et halvt år at blive produktive på et produkt? Det er kildekoden, og hvad den udtrykker. Det er ikke at lære den nye tooling, eller reglerne i det agile setup, eller de nye kode-guidelines. Det svære er at forstå forretningsproblemet, og hvordan forretningsproblemet kommer til udtryk i koden. For først når man forstår det, kan man arbejde med koden og samtidig være betrygget i, at man ikke gør koden mere besværlig at forstå for den næste udvikler.

Det er når man arbejder med koden, at man lærer at se mønstrene i den. Forstå tankerne bag koden. Forstå hvordan koblingen til domænet og brugeroplevelsen er tænkt. Forstå hvordan man udvider koden med ny kode på en hensigtsmæssig måde. Forstå hvordan begrænsningerne og mulighederne i koden har udviklet sig over tid. Når man læser kode, forstår man gradvist, hvad forfatterens hensigt var. Og måske man kan gennemskue de problemer, forfatteren løb ind i, og som gjorde, at der måtte afviges fra den oprindelige plan. Man forstår andre personers tanker nøjagtigt som når man læser alt muligt andet.

Det er i øvrigt også derfor, det er så tåkrummende åndssvagt, når ledere opfinder initiativer, som handler om, at udviklere skal bruge de samme processer og frameworks for at gøre det nemmere at skifte mellem projekter.

Den absolut nemmeste måde at lære at forstå en kodebase på med alle dens indbyggede logikker og forviklinger er ... ved at arbejde med koden. Ved at rette fejl i den, udvide den med nye behov, begå sine egne fejl, så man forstår, hvorfor det aldrig er "bare lige". Ja, faktisk ville det være stort set umuligt at lære en kodebase at kende uden at arbejde i den. Og jf. metrikken fra før - det er ikke unormalt, at det tager nye udviklere et halvt år at kunne navigere nogenlunde uhindret rundt i den eksisterende kildekode.

Hvorfor?

Fordi kildekode ikke er teknologi. Kildekode lever ikke først og fremmest i en maskine. Kode lever først og fremmest i menneskers hjerner. Kildekode opbevares på en maskine. Kildekode eksekveres af en maskine. Men kode forstås af mennesker.

Arbejde er den olie, der smører softwaren

Det mest dræbende for noget, der lever i menneskers hjerner, er ikke at lade det leve. Igen... hvis man accepterer, at det tager en ny udvikler 6 måneder at kunne navigere nogenlunde smertefrit rundt i en eksisterende kodebase, så må man også acceptere den logiske følge, at kode ikke er noget, man kan lade ligge i en database og blot finder frem ved lejlighed. For så bor det i databasen, men det lever ingen steder.

Løsningen er til gengæld enkel: Kod, for fa'en!

Systemer, som ikke udvikles aktivt, visner. De sygner hen som en afkræftet krop efter et langstrakt sygdomsforløb. Og det tager tid at få spist nok broccoli til at komme i gang igen.

Og så er det ret underordnet, hvor ny teknologien er, eller hvor god arkitekturen er.

Og omvendt: Et system, der er under aktiv udvikling, har langt sværere ved at blive til Legacy, fordi det hele tiden bliver smurt og holdt ved lige. Helt gratis af det arbejde, som flyder igennem systemet.

Synergier

Og der er andre synergier ved at lade arbejde flyde igennem kildekoden. Vores kildekode er et aktiv, vi plejer og holder ved lige, og hvis vores virksomhed er afhængig af vores kode, så investerer vi også i den. Det er først, når vi begynder at betragte kildekoden som noget "dødt", at vi stopper med at investere i den.

Vi erkender måske, at vi skal lave en større refaktorisering, før vi kan implementere den nødvendige kritiske feature. Eller at vi skal opgradere en teknologikomponent, som er ved at blive for gammel. Vi gør det kun, fordi det har en konkret og øjeblikkelig værdi for os.

Arbejde er den smørelse, som holder hele produktionsapparatet omkring koden varmt. Byg-systemet, deploy-pipelinen, aftalerne imellem os i forhold til, hvordan vi reviewer koden, men også de usagte aftaler: Hvad skal vi altid huske, når vi releaser?

Arbejde er også den smørelse, der holder gang i vores træfsikkerhed. Hvor lang tid plejer en opgave af denne type at tage? Hvor mange fejl, kan vi nå at rette på en uge?

Friktion

Når vi ikke plejer vores kode, får vi svært ved at udtrykke os i og om koden, vi bliver desorienterede i forhold til koden, vores hukommelse om koden og dens faldgruber svigter os, vi taber motivation, vi får problemer med at pleje vores kode og holde den grundlæggende soigneret, og vi har svært ved at forstå dens grundlæggende opførsel.

Det samme kan ske for mennesker: sprogvanskeligheder, desorientering, hukommelsestab, motivationstab, mangelfuld personlig pleje og svært forklaring opførsel.

Det kalder vi demens.

Og selvom sammenligningen indrømmet er ved at være en anelse på afveje, så er det faktisk ikke helt ulig det, vi udsætter vores kodebase for, når vi ikke arbejder i den.

Conways Lov

På organisationsniveau har Conway udtrykt det igennem sin kendte lov.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Melvin E. Conway

Conways lov opstår, fordi vi løser problemer med den kildekode, vi kender. Vi ser verden igennem vores kildekode, fordi det er den mest effektive og naturlige måde for os at arbejde på. Hvis vi skulle løse et nyt problem og gøre det i en ukendt kodebase, ville det føles som en uoverstigelig fordyrelse af løsningen.

Derfor bygger vi systemer op omkring det, vi er i nærheden af, og vi undgår at pille ved de systemer, vi ikke arbejder i.

Ved næste organisationsændring har vi med andre ord skabt nye Legacy-systemer. Nye systemer, som nogen arver og vil forsøge ikke at (des-)orientere sig i. Systemer, som arbejdet ikke vil flyde igennem og over tid smøre alle hjørner i.

Løsningen

Det er dyrt at pensionere systemer eller modernisere dem, fordi de blev til legacy-systemer.

Måske vi skulle tillade os selv at regne på, om det kan svare sig tidligt at investere sig ud af kode-demensen? Når vi har søsat et projekt og når den fase, hvor vi ikke har arbejde nok til projektet, så skal vi måske ... blive ved med at finde på arbejde? Jeg ved det ikke, men det kunne da være sjovt at regne på. Måske det over systemets levetid var en god case.

Måske er det faktisk billigere bare at holde et fuldt team på projektet år ud og år ind, selvom det er svært at forsvare forretningsmæssigt i øjeblikket, end det er at lade koden sygne hen og om 10 år risikere at skulle re-implementere hele projektet fra ende til anden.

I moderniseringsøjemed er et team i 10 år måske slet ikke så meget endda?