DevOpsTechnical Debt (h)erkennen en op de backlog zetten

Technical Debt (h)erkennen en op de backlog zetten

TechnicalDebt_postercartoon

Technical debt is een veelgehoorde term. De
oorsprong ligt (onofficieel) in Maart 1992, toen Ward Cunningham dit benoemde tijdens de OOPSLA conferentie. Technical debt werd daarbij vergeleken met financial debt. Bij financial debt (schuld) zorgt voor extra kosten (rente). Net als een financiële schuld moet je ook bij technical debt extra kosten maken. Deze komen in de vorm van de extra inspanningen die we in toekomstige ontwikkelingen moeten doen, doordat we niet de beste oplossing hebben gerealiseerd maar de op dat moment snelste oplossing (denk hierbij aan "shortcuts" en "quick and dirty" oplossingen).

Gevolgen van technical debt

Waarom is het eigenlijk van belang om aan het verminderen (of beter het voorkomen) van technical debt te werken? Wanneer de software technical debt bevat dan kom je vaak onderstaande consequenties tegen:
- Code wordt onbeheersbaar
- Ontwikkelaars worden overdreven gespecialiseerd
- De oplossing wordt inflexibel
- Medewerkers worden gedemotiveerd
- Leveren van waarde wordt steeds moeilijker

Ik zal 2 voorbeelden hieronder uitwerken.

Ontwikkelaars worden overdreven gespecialiseerd - Ik denk dat veel mensen deze situatie wel herkennen. Om een bepaalde oplossing te realiseren of om in een bepaald stuk code te werken krijg je te horen: Dat moet je even aan Wilfred vragen, hij heeft deze code gemaakt en weet als enige hoe het werkt. Gevolg van deze situatie is dat deze medewerker vaak teveel werk op zich af krijgt en hier een bottleneck ontstaat. Ook kan deze medewerker bijna niet op vakantie, want wat als er een fout optreed? Wilfred is de enige die het op kan lossen … Al met al voor het bedrijf, maar ook voor de medewerker, geen ideale situatie!

Leveren van waarde wordt steeds moeilijker - Ik heb bij verschillende bedrijven gezeten waarbij er door nieuwe zakelijke contracten in dezelfde tijd mee waarde geleverd moest worden. Het was in deze gevallen lastig om dit te realiseren. Doordat een applicatie al meer dan 10 jaar oud was, de mensen die aan de wieg hadden gestaan al lang weg waren, en de code zeer complex was kon er niet worden opgeschaald. Een nieuwe medewerker inwerken kostte al 3 – 6 maanden (minimaal) en in deze periode moesten mensen je ook nog inwerken. Oftewel, de velocity van het gehele team gaat omlaag als je mensen opschaalt. En niet voor 2 – 3 Sprints wat normaal is maar een veel langere tijd. Daarnaast kon een nieuwe medewerker pas complexere vraagstukken oppakken wanneer hij of zij meer dan 2 – 3 jaar werkzaam was in het team. Gevolg is dat opschalen, zeker op korte en zelfs middellange termijn, nagenoeg onmogelijk is!

Hoe herken je technical debt

Ook als je geen tooling gebruikt om technical debt te meten zijn er een aantal indicatoren waaruit je kunt afleiden dat er sprake is van technical debt is en dat deze toeneemt.

- De velocity neemt af;
- De kwaliteit neemt af (het aantal bugs neemt toe na een release)
- De tevredenheid van het team neemt af
- Productie issues die worden verholpen komen terug en moeten dus meerdere keren worden opgelost

Wat ik tijdens mijn opdrachten veel ben tegengekomen zijn de voorbeelden waarbij de kwaliteit inderdaad afneemt. Na een release komen er steeds meer fouten naar voren, door code aan te passen of nieuwe code toe te voegen treed een fout op in een deel van de applicatie waar je niets hebt aangepast. Op de een of andere manier is er een relatie zonder dat deze bekend is.

Ook het herhaaldelijk moeten oplossen van dezelfde productie issues komt vaak voor. Na een release komt een oude fout opeens weer naar voren, of de oplossing werkt net niet goed en moet dus een aantal keer over worden gedaan.

Uitingen die wijzen op technical debt

Als je rondloopt in een team op of een afdeling zijn er een aantal opmerkingen die je opvangt die wijzen op het bestaan van technical debt. Zonder dat je tooling gebruikt zijn dit aanwijzingen die je direct moet oppakken. Wees hier dus alert op, hoor of merk je een van onderstaande zaken op? Ga dan met het team om tafel en bespreek hoe hiermee om te gaan.

- "Maak je geen zorgen over de documentatie voor nu."
- "De enige die deze code kan veranderen is Wilfred."
- "In de code het commentaar ToDo / FixMe: dit moet worden opgelost voor de productie uitrol"
-"Weet iemand waar we het database wachtwoord opslaan?"
- "Ik weet dat als ik hier iets aanpast daar in de applicatie iets om kan vallen."
- 'Laten we gewoon onze QA-tijd gebruiken om die functie af te bouwen.'
- "De klant geeft er niet om, doe het gewoon!

Wanneer is de kans op ontstaan technical debt het grootst

Wanneer een nieuw project wordt gestart is het nooit de intentie om technical debt te ontwikkelen, toch is het iets wat er insluipt. Over het algemeen wordt dit veroorzaakt door tijdsdruk. In het begin is het team en de organisatie er scherp op technical debt niet te laten ontstaan. Als deadlines dichterbij komen dan wordt dit echter snel vergeten. Het op tijd opleveren van de oplossing wordt belangrijker dan het goed opzetten en bouwen van de software (en dus een vertraging te accepteren). Hieronder een plaatje wat dit goed weergeeft, in het begin is het nog geen probleem dat we minder functionaliteit opleveren. Er wordt nog gedacht dit later in te halen, maar als blijkt dat dit niet het geval is wordt vaak niet de opleverdatum opgeschoven zodat we een goede oplossing kunnen bouwen. Er wordt gezocht naar een manier om toch op tijd op te leveren, dit gaat altijd ten koste van de kwaliteit (en onderhoudbaarheid van de software).Technical Debt Scope vs. Time

Technical debt quadrant

Martin Fowler heeft de technical debt kwadrant geïntroduceerd. Hierin wordt een onderscheid gemaakt hoe je met technical debt omgaat.  Wanneer je in een organisatie werkzaam ben is het goed om met deze verdeling rekening te houden. Afhankelijk van in welk kwadrant je zit zijn de maatregelen ook anders.

Technical debt quadrant

Martin Fowler: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

Reckless - Deliberate

Als je als team er bewust van bent dat je technical debt creëert, maar er toch geen aandacht aan besteed dan ben je "reckless" .

Reckless - Inadvertent

Je bent je als team niet bewust van het feit dat je technical debt creeert, gevaarlijk aan deze situatie is dat je niet herkent en dus ook niet bewust een risico neemt.

Prudent - Deliberate

Als je als team er bewust van bent maar er wel aandacht aan besteed ben je "prudent". Je kiest bewust voor het oplopen van technical debt ,maar je calculeert al direct in dat je dit gaat oplossen na de oplevering. Het halen van een deadline kan belangrijk zijn, en dus kies je voor de snelle oplossing, maar direct na oplevering ga je dit oplossen. Het is aan een ieder om hier een eigen keuze in te maken.

Prudent - Inadvertent

Je bent je als team niet bewust van het feit dat je technical debt creëert, toch herken je als je klaar bent dat je de oplossing op een andere manier had moeten realiseren.

Hoe krijg je inzicht in de technical debt

Om technical debt aan te pakken is het goed om eerst inzicht te krijgen in de aard en hoeveelheid technical debt. Dit inzicht verkrijg je door gegevens te verzamelen. Een van de belangrijkste gegevens zijn Code metrics. Er zijn een aantal onderdelen die je kunt meten, denk hierbij aan:

- Complexiteit van de code

- (Unit) test coverage

- Hoeveelheid gedupliceerde code

- Kwetsbaarheden (bv op basis van de OWASP top 10)

- Aantal regels code (total)

- Aantal regels code (per functie)

Door te meten krijg je inzicht in de huidige situatie, hiermee los je het probleem niet op maar je kunt wel al met elkaar afspreken dat je bepaalde waarden niet laat stijgen (bv. hoeveelheid gedupliceerde code) of niet laat dalen (bv. (Unit) test coverage).

Tools om technical debt te meten

Meet gegevens verzamelen is belangrijk, dit zou je met de hand kunnen doen maar dat is zeer inefficiënt. In de afgelopen jaren zijn er verschillende tools op de markt gekomen die de technical debt meten. Deze tools kun je zodanig inzetten dat ze dagelijks, of zelfs als onderdeel van het build proces, gegevens verzamelen. Dit geeft een goed inzicht in de ontwikkeling van technical debt. Als het op dit moment bijvoorbeeld 103 dagen is dan kun je dat veel of weinig vinden, als team kun je in ieder geval afspreken dat dit met elke release niet toeneemt. Door dit af te spreken is de eerste stap genomen in het onder controle krijgen van de techncial debt.

Er zijn verschillende tools die technical debt meten, bijvoorbeeld:
- SonarQube
- nDepend

Naast tooling zijn er ook organisaties die technical debt meten, deze organisaties gebruiken zeker ook tooling maar kijken verder dan alleen technical debt. Ze kijken ook naar bijvoorbeeld de onderhoudbaarheid van de code en de documentatie. Enkele van deze organisaties zijn:

SIG (Software In Group)

IFSQ (Institute for Software Quality)

De controle door deze organisaties geven vooral inzicht naar buiten de organisatie, het is immers een onafhankelijk instituut dat een oordeel velt. Ik heb bij bedrijven gezeten waarbij klanten het op prijs stelde dat het SIG een controle deed. SIG geeft op basis van de controle een score (van 0 tot 5, op decimalen dus je kunt een 4,3 scoren). Over het algemeen is een score van 3,0 of hoger voldoende.

Technical debt op de backlog krijgen

Het lijkt voor de hand te liggen, maar technical debt oplossen is niet altijd eenvoudig. Niet alleen vanuit technisch oogpunt, maar ook vanuit business perspectief. Immers, op korte termijn kost het veel tijd en in het beste geval doet de applicatie nog wat hij deed. Alleen nu na een aantal uur werk, de business ziet dus geen toegevoegde waarde. Deze is er uiteraard wel, maar je moet er als team voor zorgen dat het op de backlog komt te staan. Praat met de product owner en doe dat in termen van wat het kost als je het niet oplost:

Als we technical debt niet oplossen kost het 1 FTE extra om deze functionaliteit op te leveren door verlies aan snelheid

We kunnen met dezelfde team omvang 10% minder value leveren elk jaar

We kunnen niet opschalen omdat teamleden moeilijk zijn in te werken en de code te complex is

Onze Net Promotor Score zal omlaag gaanTechnical debt

Conclusie

Technical debt weerhoud je van het daadwerkelijk sneller value leveren aan de eindklant. Wil je als team dus een hogere productiviteit behalen is het een must om de technical debt onder controle te krijgen en zo veel als mogelijk te reduceren. Een technical debt van nul is geen doel op zich, er zal altijd iets van technical debt zijn. Bepaal samen met het team wat acceptabel is en werk aan het meten en terugdringen hiervan.

Marcel Groennou, DevOps Consultant