Et fascinerende begreb, som er super irriterende i virkeligheden, er smitsom teknisk gæld. Det er en ‘nyere’ type af teknisk gæld. Den går i al sin enkelthed ud på, at teknisk gæld ét sted kan gøre, at teknisk gæld også opstår andre steder – enten i virksomheden eller i andre systemer eller komponenter.
Så hvordan adskiller smitsom gæld sig fra gæld med høj rente?
Når man stifter teknisk gæld og undlader at håndtere det, kan det vokse sig større i den forstand at jo længere man venter, jo mere besværligt bliver det at rette op igen (renten). Hvorimod når man stifter teknisk gæld i et system, kan det sprede sig til andre systemer.
Smitsom gæld er, når et system eksempelvis tvinger andre systemer til at foretage nogle uhensigtsmæssige beslutninger. Derved skelner man mellem smitsom gæld og renten på en gæld.
Eksempel – Teknisk gæld der smitter
Eksemplet tager udgangspunkt i et sagshåndteringssystems API, et API er en “bro” eller et interface, der forbinder to forskellige systemer. Sagshåndteringssystemets API er bygget til at man kan ændre en ting på en sag. Men det er ikke bygget til at man på én gang kan ændre flere ting på sagen på én gang, hvilket betyder at hvis man skal lave flere ændringer, skal de ske én ad gangen og ikke som en samlet opdatering. Dette forringer transaktionsmodellen. Dette medfører begrænsninger på nye systemer, som skal interagere med sagshåndteringssystemet. Udfordringen er, at man risikerer at kopiere den dårlige transaktionsmodel på data, der håndteres internt i systemet. Transaktionsmodellen er allerede i stykker, så man “opdager” eller mister ikke noget på ikke at gøre det rigtigt.
På den måde kan en begrænsning i et centralt systems API øge kompleksiteten i andre systemer. Det er særlig vanskeligt at få det udbedret, for alle rettelser skal ske samtidig for at tingene kan fungere. Denne mindre big-bang ændring af dette skal ske på ca. 0 sekunder, da alle systemer vil være nede i mens ændringen sker. Fordi dette er løsningen, har det forhindret organisationen i at få rettet op på den tekniske gæld. De store problemer med de smitsommme gældsposter er, at det er yderst vanskeligt at lave dem om.
Legacy, der smitter
Vi forklarede i forrige blogindlæg (link) at legacy systemer ofte har integrationer til gamle tredjepartskomponenter, eksterne systemer og standardløsninger, hvilket skaber afhængigheder. Dermed ‘smitter’ de gamle tredjepartskomponenters legacy gennem integrationerne til de ‘nærmeste’ systemer. Altså kan legacy systemer fastholde andre systemer i en specifik version, fordi det er vanskeligt at opgradere. Derfor er det så vigtigt at have styr på sin supply chain, så man rettidigt kan gøre opmærksom på problemerne, da det er nemmere at håndtere dette i opløbet.
Eksempel på smitsom legacy
Forestil dig en situation, hvor et system er bygget på en ældre Java version. Denne gamle version skaber en kæde af problemer, da mange nyere biblioteker og komponenter ikke længere understøtter den ældre Java version. Resultatet er, at disse biblioteker ikke kan opdateres til de seneste versioner. Dette problem med forældede biblioteker er ikke isoleret; det spreder sig til andre dele af systemet eller endda til andre systemer, der er afhængige af de samme biblioteker. Det betyder, at hele dele af systemlandskabet fastholdes i den gamle Java-version. Med tiden bliver det sværere at opgradere og legacy spreder sig på den måde til andre systemer.
Rod avler mere rod
Hvis det roder lidt i den ene ende af systemet, hvad skal så stoppe det fra at der også kommer til at rode i den anden ende af systemet eller i ‘søstersystemet’. Her benyttes Wilson og Kellings teori om broken windows, man er nødt til at slå ned på de små fejl, så man kan afholde de store. Argumentet kan netop være at hvis det roder her, hvorfor skal man så gøre det ordentligt herover eller rydde op? Manglende eller utydelig dokumentation kan også bidrage til ‘rodet’. Hvis ingen ved, hvordan tingene fungerer, er det svært at gøre det ordentligt og undgå at skabe mere teknisk gæld. Derfor er orden og følge standarder (og tilsvarende) centralt for at undgå konsekvenserne af ‘broken windows’ og minimere den teknisk gæld.
En type af teknisk gæld kan lede til den næste type, eksempelvis en genvej i et system kan forringe performance i et andet. Dette kan skabe en dominoeffekt, hvor problemerne gradvist eskalerer og spreder sig. Hvilket efterlader et kæmpe efterslæb. Denne tendens til at rod breder sig, understreger vigtigheden af at se ‘smitte’ som en metrik.
Smitte som en metrik
Smitsom gæld låser ikke bare et system, man risikerer at det låser store dele af organisationens systemlandskab. I arkitekturen bør man derfor fokusere på lav kobling, jo lavere kobling mellem systemer, jo mindre er risikoen for at smitte. I dagligdagen kan man tænke smitsomhed ind som en af de metrikker man kigger på når man vurdere eller måler på teknisk gæld opgave. Hvis den tekniske gæld fortsætter med at eksistere, hvor meget vil den så sprede sig?
Spredning kan skyldes, at andre systemer interagerer med det berørte system, at kopiere og indsætte data bygget oven på systemet, eller at påvirke den måde, andre udviklere implementerer nye funktioner på. Hvilket vi også så med de to eksempler.
Hvis den tekniske gæld er godt inddæmmet, er omkostningerne ved at reparere den senere sammenlignet med nu stort set identiske. Man kan overveje, hvor stor indflydelse den har i dag, når man skal bestemme, hvornår en løsning giver mening. Hvis en teknisk gæld derimod er meget smitsom, bliver det sværere og sværere at reparere. Det, der er særligt ubehageligt ved smitsom teknisk gæld, er, at dens indflydelse har en tendens til at stige, efterhånden som flere og flere systemer bliver inficeret af det tekniske kompromitterende element i dens kerne. På den måde opfører den tekniske gæld sig som en virus, der kan skabe en epidemi i systemlandskabet.
Negativ spiral
Smitsom teknisk gæld og legacy er en væsentlig drivkraft til at skabe en negativ spiral, da legacy og gæld skaber problemer og gør systemerne sværere at arbejde med. Foruden smitten i it-landskabet, ved man, at det er demotiverende for et team at arbejde i systemer, der er tynget med teknisk gæld og legacy. Det forringer moralen, produktiviteten, softwarens levedygtighed og fodrer ikke til fejlfrie systemer. Fordi teknisk gæld hindrer udviklernes fremskridt og reducerer deres selvtillid. Altså kan teknisk gæld føre teamet ind i en negativ spiral. Manglende kommunikation og vidensdeling om systemets kompleksitet kan forværre situationen. Udviklere føler sig isolerede og problemerne kan virke som en uoverkommelig opgave.
Eksempel på den negative spiral
Den negative spiral kan have store konsekvenser. Udviklere udtrykker ubehag ved at arbejde i systemer med meget teknisk gæld og legacy, da det ofte føles umuligt at foretage ændringer. Nye systemer er heller ikke altid løsningen. Eksempelvis forsøgte man at erstatte et ældre system med et nyt, som var fyldt med mangler og ineffektive løsninger. Efter en test kasserede man det nye system, fordi det var så dårligt at det førte til øget arbejdsbyrde og stress hos medarbejderne. Her var det dårlig kode, dokumentation, behovsafklaring og arkitektur årsagerne til øget arbejdsbyrde og de endelige stresssygemeldinger.
Positiv spiral
Der er gode nyheder, for korrekt håndtering af teknisk gæld booster teamets moral, da det gør det muligt for dem at udføre deres opgaver bedre og forbedre software kvaliteten fremadrettet. Så korrekt teknisk gæld håndtering fører til en positiv spiral, hvor den rigtige kultur og forebyggelsesaktiviteter forstærker hinanden, hvilket fører til mindre spild af tid, efterfulgt af en kontinuerlig stigning i udviklernes moral og produktivitet. Hvilket starter med åben kommunikation, regelmæssige møder om teknisk gæld, prioritering af opgaver og deling af viden om systemet skaber en positiv spiral. Ved at fokusere på at identificere og håndtere smitsom gæld, kan man bryde den negative spiral og i stedet skabe en positiv spiral.
Eksempel på den positive spiral
Vi ser flere teams som løbende holder deres teknisk gæld nede. De fortæller stolt om deres fremgang med at løse den tekniske gæld og hvilken betydning det har for systemet. For eksempel fik en udvikler løst teknisk gæld udfordring, så nogle tests endelig stoppede med at fejle og kørte korrekt. Dette førte til så stor en lettelse, at der blev lovet fejring for at markere succesen.
Den korte version
Teknisk gæld og legacy kan udvikle sig til en epidemi i it-landskabet. Smitsom teknisk gæld og legacy er en af de primære årsager til den negative spiral, og at håndtering af smitsom gæld er afgørende for at skabe den positive spiral. Derfor bør ‘smitsomhed’ indgå som en metrik i vurderingen af teknisk gæld. Korrekt håndtering af den smitsomme gæld kan skabe en positiv spiral, men hvad sker der, når gælden bliver for omfattende? I næste blogindlæg udforsker vi, hvad man gør, når den eneste løsning er at lukke systemer ned.
Læs de andre indlæg i blogserien
Kilder
- Cerny, T., Chy, M., Abdelfattah, A., Soldani, J., & Bogner, J. (2024, May). On maintainability and microservice dependencies: How do changes propagate?. In Proceedings of the 14th International Conference on Cloud Computing and Services Science-CLOSER, Prague, Czech Republic (pp. 1-3). https://www.scitepress.org/Papers/2024/127252/127252.pdf
- Besker, T., Martini, A., & Bosch, J. (2018, May). Technical debt cripples software developer productivity: a longitudinal study on developers’ daily software development work. In Proceedings of the 2018 International Conference on Technical Debt (pp. 105-114). https://www.duo.uio.no/bitstream/handle/10852/73978/ICSE-CE-TechDebt-40.pdf?sequence=2
- Martini, A., & Bosch, J. (2015, August). Towards prioritizing architecture technical debt: information needs of architects and product owners. In 2015 41St euromicro conference on software engineering and advanced applications (pp. 422-429). IEEE. https://www.researchgate.net/profile/Antonio-Martini-3/publication/279925622_Towards_Prioritizing_Architecture_
Technical_Debt_Information_Needs_of_Architects_and_Product_Owners/links/55a3dbac08aef8052354011d/Towards-Prioritizing-Architecture-Technical-Debt-Information-Needs-of-Architects-and-Product-Owners.pdf
- Clark (2018) A taxonomy of tech debt https://technology.riotgames.com/news/taxonomy-tech-debt
- Besker, T., Ghanbari, H., Martini, A., & Bosch, J. (2020). The influence of technical debt on software developer morale. Journal of Systems and Software, 167, 110586. https://acris.aalto.fi/ws/portalfiles/portal/42987670/Pre_proof_MTD_JSS.pdf
Har du spørgsmål – eller bare lyst til en snak?
Mille Kjærsgaard Hansen
Senior Consultant
Mille har en Ph.d. i styring af teknisk gæld i den offentlige sektor og specialiserer sig i at analysere komplekse problemstillinger, omsætte dem til konkrete udfordringer og finde gode løsninger.
Hun deler glædeligt ud af sin viden om tekgisk gæld og legacy både gennem blogposts, oplæg og workshops. Derudover formidler hun sin viden på alle niveauer og relevante områder i organisanisationen.
mkh@nine.dk
+45 60 58 88 03
Har du spørgsmål – eller bare lyst til en snak?
Casper Lund Junge
Direktør
Casper har speciale i digital transformation. Han har flere års erfarfing i at bistå virksomheder med at finde vej i det digitale landskab – altid med en god balance mellem strategi og teknologi.
Han har en stærk baggrund i både rådgivning og salg og står i dag i spidsen for én af Nines fem forretningsenheder. Her driver han forandringer, der gør en forskel for kunderne – og han brænder for at skabe løsninger, der virker i praksis.
clj@nine.dk
+45 30 93 49 31