Interne kennissessie over Technical Debt

Afgelopen vrijdag zwermden de Covadianen van hun vertrouwde werkplekken af om de bekende bar te betreden. Niet voor de vrijdagmiddagborrel, daar was het te vroeg voor, maar voor een nieuwe kennissessie. Een leermoment dat geregeld op vrijdag plaats vindt. Eén van onze softwarearchitecten vertelde daar alles over Technical Debt.

De aanwezige collega’s luisterden in opperste concentratie naar de deskundige spreker. Een kennissessie Technical Debt draait voornamelijk om twee zaken. Code moet van hoge kwaliteit zijn en het moet gemakkelijker te onderhouden zijn. Technical Debt is iets wat onze ontwikkelaars zoveel mogelijk willen voorkomen. In de sessie kwamen verschillende zaken aan bod.

  • Het verbeteren van bestaande code.
  • Het proces overzichtelijk maken.
  • Het onderhoudbaar maken en houden van de software.
  • De code controleren op Technical Debt.

Een tijdvreter

“Technical Debt is vooral een tijdvreter”, legt de architect uit. “Een ontwikkelaar spendeert een groot deel van de tijd aan het lezen en het onderhouden van code. Hoe complexer en onoverzichtelijker een code is, des te meer tijd dit kost. Het is dus essentieel om te analyseren hoe complex code in elkaar steekt. Leer Technical Debt voorkomen door het te herkennen.”

Uiteindelijk is tijd geld en zodra iets meer tijd kost worden planningen niet gehaald. Het loont dus om te waken voor complexiteit.

Om de kern van Technical Debt te illustreren wordt een beeldende quote van softwareontwikkelaar Martin Fowler aangehaald.

“Net als een financiële debt komen bovenop een Technical Debt rentebetalingen. Betalingen in de vorm van de extra inspanning die gedaan wordt in de verdere ontwikkeling, omdat de code te snel en slecht is ontworpen.”

Als een ‘vuil’ systeem wordt doorontwikkeld, wordt de complexiteit groter tenzij er werk wordt verzet om de code te onderhouden en het geheel overzichtelijker te maken. Het is risicovol om verder te ontwikkelen op basis van ‘foute’ code.

Herkennen

Technical Debt is te herkennen aan de situaties die kunnen voorkomen in het ontwikkelproces. Enkele voorbeelden zijn:

Maar één persoon in een bedrijf kan iets maken of repareren.

De hele applicatie moet extra getest worden als een enkele feature geïmplementeerd wordt.

Het duurt lang om een toepassing in productie te nemen na een kleine aanpassing.

Naast het feit dat het lang duurt voor iets is opgelost, kan het door de toenemende complexiteit nieuwe bugs opleveren. Dan hebben we het er nog niet eens over de grote hoeveelheid frustratie voor de ontwikkelaar. Ook dit speelt een belangrijke rol bij Technical Debt.

Technical Debt komt in verschillende verschijningsvormen. Bijvoorbeeld:

  • Cyclomatisch complexiteit
  • Veel lines of Code
  • ‘Foute’ structuren (voorbeeld GOTO of Temporal coupling)
  • Structural indents
  • Duplications

Hotspots

Knelpunten waar een grote kans op Technical Debt is worden Hotspots genoemd. Deze Hotspots moeten in kaart worden gebracht, zodat de kans op Technical Debt minimaal is en voorkomen kan worden. Gelukkig zijn daar mooie tools voor:

  • GitHub
  • Coach City
  • SonarQube
  • Coach Scene

Uiteraard werden deze tools in de Kennissessie besproken. Hetzelfde geldt voor de verschillende manieren waarop Technical Debt voorkomen wordt.

Zo wordt bij Covadis er alles aangedaan om de code op een nette manier in een zo kort mogelijke tijd te ontwikkelen. De code is altijd op de best mogelijke manier ontwikkeld voor de opdrachtgever. Als Covadis staan we er steevast achter.