12 donkere geheimen van technical debt

Je hoort vaak praten over 'technical debt', technische hiaten die uit het verleden stammen en nu voor problemen zorgen. Maar zijn die problemen eigenlijk wel allemaal reëel?

Ooit maakten programmeurs zich geen zorgen over het verleden. Ze openden een leeg bestand en maakten iets uit het niets. Alles was nieuw en niet belast met erfenissen uit het verleden..

Die vrije, onbezwaarde dagen zijn voor de meesten van ons al lang voorbij. Veel in de huidige softwareontwikkeling is het herzien, uitbreiden, verbeteren en ontwikkelen van wat we - of vaker, iemand anders - voorheen deden. We zitten dus met technical debt, zoals dat zo mooi heet.

De term technical debt is ook bij ons gangbaar geworden (in plaats van de vertaling naar het Nederlands, technische schuld) en het is een nuttige manier om te verwijzen naar iets wat nog niet is opgelost. De 'debt' is dat we nu terug moeten gaan en de leemten moeten opvullen of aanvullen, in wat we vorige week, vorige maand of zelfs jaren geleden hebben gedaan.

In de planningsfase is de term een goede afkorting voor werk dat vaak wordt vergeten. Belanghebbenden zijn al bezig met het opstellen van lijsten met nieuwe functies en verbeteringen, maar als niemand kijkt wat er al is gedaan, zullen alle oudere verbeteringen nooit hun volledige potentieel bereiken. Ze zullen voor altijd verstrikt blijven in ontbrekende of gebroken code die op het verkeerde moment faalt.

Het lastige deel van de zinsnede is het woord 'debt', dat een verplichting aanduidt, soms moreel en soms juridisch. Het gijzelen van schuldenaars wordt zelden meer gedaan, maar in de softwarewereld kan technical debt een soort gijzeling op zich zijn - als het niet kan worden genegeerd.

Hier zijn 12 duistere geheimen over wat we onze softwarestacks verschuldigd zijn.

Technical debt is niet inherent slecht

Het woord 'debt' klinkt slecht, maar het geeft niet altijd een slecht oordeel weer. De technical debt komt bijna altijd voort uit een periode van nieuwe ontwikkelingen die de stapel hebben uitgebreid met een aantal nieuwe functies. De ontwikkelaars hebben niet alles op de lijst gekregen en hebben niet iedereen gelukkig gemaakt, maar zich daarop concentreren is gericht op het negatieve. Het glas mag dan halfvol zijn, maar er zat nauwelijks iets in voordat ze begonnen. De technische schuld is echt de schaduw van de vooruitgang.

De technical debt is echt oneindig

De lijst van technical debt lijkt misschien overweldigend genoeg, maar de echte lijst strekt zich rechtstreeks uit tot de maan en verder. Het is echt een lijst van dingen die de software niet doet en deze lijst is oneindig. Je kunt je concentreren op het feit dat het PDF-bestanden niet correct exporteert of dat een CSS-selector te algemeen is, maar het implementeert ook niet tientallen nieuwe AI-algoritmen of kwantum-veilige encryptie-algoritmen. Leest het gedachten? Weet het welke nieuwe mode in spijkerbroeken de kinderen volgend voorjaar zullen willen kopen? Over vijf jaar?

Het punt is dat de technical debt onmogelijk te meten of te codificeren is. Als je echt hard werkt, sla je de lunch over en kom je halverwege de oneindigheid en raad eens? Oneindigheid is nog net zo ver weg en morgen heb je nog een lange weg te gaan.

Technical debt is niet altijd verschuldigd

Of er sprake is van technical debt hangt af van wie ernaar kijkt. Chris kan erop aandringen dat we het data-archief moeten uitbreiden of een API moeten herbouwen om een andere zoekopdracht te accepteren, maar Chris besteedt ook de helft van de avond aan het argumenteren over Area 51 op Reddit. Dit is niet om een oordeel te vellen over de vraag of aliens zich werkelijk in Area 51 bevinden. Ik wil er alleen maar op wijzen dat de meeste bedrijven in staat zijn geweest om het prima te doen zonder een beslissing te nemen over deze intrigerende zaak. Hetzelfde zou kunnen gelden voor de API-featureset die Chris wil implementeren. Misschien heeft Chris gelijk. Of misschien is Chris op expeditie naar de ruimte. Wat zal het zijn?

Niemand int die 'debt'

Technical debt is niet zoals een financiële schuld waarbij de bank je softwareplatform komt halen als je niet betaalt. Ook zullen er geen deurwaarders aankomen om er midden in de nacht vandoor te gaan met je code. Technical debt zijn puur een intern boekhoudmechanisme dat ons kan helpen bij het opsporen van wat er moet gebeuren. Het is als een van die "To-Do"- notitieblokken, maar dan met een veel beter buzzwoord.

Technical debt lijken soms op financiële schulden

Het lastige van technical debt is dat sommige technical debt financieel ernstig zijn. Misschien zal een belangrijke klant vertrekken als de API JSON niet ondersteunt. Misschien is er een nieuwe concurrent die klanten steelt door aan te bieden om met NoSQL databases te werken. De uitdaging is om het bedrag van deze financiële risico te meten en vervolgens een verstandige zakelijke beslissing te nemen. Als het nadeel van het negeren van de debt veel minder is dan de kosten van het oplossen van die debt, dan is het zinvol om het te negeren. Maar als het financiële risico hoog is, nou ja, dan is het tijd om aan de slag te gaan en dat probleem op te lossen.

Technical debt kan een politieke fictie zijn

Veel mensen die wat technical debt willen oplossen zijn stevig geworteld in een of ander politiek kamp en ze gebruiken de term "debt" omdat het overtuigender en ernstiger klinkt dan om iets op een "technisch verlanglijstje" te zetten. Deze mensen kunnen wel of niet belangrijk zijn voor de toekomst van het bedrijf en de software waar je aan werkt. Als je bedrijf meer contracten wil krijgen in Amsterdam, nou ja, dan kan het goed zijn om ervoor te zorgen dat jouw software goed werkt met de big spenders in Amsterdam. Als dat niet een belangrijk deel van de doelstellingen van het bedrijf is, dan hoeft de debt misschien niet worden opgelost..

Technical debt verdwijnt soms gewoonweg.

Veel mensen hebben de mazzel bij het negeren van huiduitslag dat het lichaam het genezingswerk op eigen kracht goed doet. Ook technical debt verdwijnt vaak vanzelf. Het lijkt misschien belangrijk om vandaag een essentieel bestandsformaat te ondersteunen, maar soms komt er een nieuw bestandsformaat langs, dat het oude overschaduwt en het onnodig maakt om dat oude formaat te ondersteunen omdat iedereen het is vergeten. Er zijn miljoenen scenario's waarin de technical debt gewoonweg verdampt. Het negeren ervan is een heel goede strategie, net als het negeren van huiduitslag - zolang je er maar zeker van bent dat het geen huidkanker is.

Technical debt is moeilijk vast te stellen

Is wat iemand in het team "technical debt" noemt echt een debt? Of is het gewoon een functie die iemand wil? Wat zijn we onze gebruikers verschuldigd?

Technical debt kan vaak slechts cosmetisch zijn

Soms blijkt een kenmerk dat in de definitie van technical debt valt, slechts cosmetisch te zijn. Dit is altijd een kwestie voor managers. Sommige problemen vereisen een uitgebreide herschrijving van grote delen van de huidige softwarestack en andere kunnen worden geëlimineerd door een slimme ompakking van de huidige codebasis. De uitdaging is om de morele mist te doorzien van iets dat klinkt als technische tekortkoming en praktische beslissingen te nemen over het aanbieden van functies die het minst kosten om te leveren.

Technical debt wordt nooit vereffend

Scenarioschrijvers houden van schulden omdat ze de hoofdrolspeler besturen en een mooie, bevredigende oplossing hebben. In een film moet Nick Cage 50 auto's stelen. Na 49 is hij nog steeds in de schulden. Wanneer de 50e wordt afgeleverd, is hij op vrije voeten. De schuld is vereffend. Het geld rolt.

Technical debt is niet hetzelfde. Oh zeker, als je eenmaal begint met het accepteren van XML-bestanden, zal je geen gerichte verzoeken van je baas meer krijgen. Je kunt die tickets afsluiten en een grote sprong zien in de grafiek van gesloten tickets. Maar 9 van de 10 keer zal de goede daad gewoon nieuwe debt genereren. De verzoeken om XML-invoer zullen worden gevolgd door technische ondersteuning voor deze nieuwe functie. Nieuwe code zorgt voor nieuwe uitgaven en de technical debt wordt verrekend met nieuwe code.

Technical debt is niet numeriek - en dus moeilijk te meten

Waar een financiële schuld wordt gemeten in aantallen, kan technical debt niet worden gemeten zonder met handen te zwaaien. Zeker, de agile club zal proberen het aantal "punten" te tellen dat het zal kosten om iets te implementeren. Slimme managers zullen in staat zijn om de tijd van de ontwikkelaar in uren te schatten. Maar dat zijn allemaal gissingen en er kan van alles gebeuren. Het doet je verlangen naar de gangsterfilms met de woekeraar die precies weet hoeveel euro hij wil.

Technical debt kan een kans zijn

De oude grap gaat dat als je de bank 100.000 euro schuldig bent, je in de problemen zit, maar als je de bank 100 miljoen euro schuldig bent, zit de bank in de problemen. Sommige ontwikkelaars kunnen over debt praten alsof het iets is wat je schuldig bent, maar het is meer een (bluf)spel tussen klant en leverancier.

Als dat maakt dat iemand zijn business naar een ander kan brengen, dan moet je die business verdienen. Je kunt beter je code repareren. Maar als die iemand echt je stack nodig heeft en niet gemakkelijk kan migreren, kan de technical debt echt een kans zijn om iemand te upsellen. Hoeveel zullen je gebruikers betalen voor de nieuwe functie?

Copyright © 2019 IDG Communications, Inc.

Discover what your peers are reading. Sign up for our FREE email newsletters today!