69 procent van de it-professionals beschouwt technical debt als een grote bedreiging voor het innovatievermogen van hun bedrijf. Gemiddeld wordt hier dan ook 41 procent van het it-budget aan besteed. Daarnaast zegt 61 procent dat het de prestaties van hun bedrijf afremt en is 64 procent het ermee eens dat technical debt ook in de toekomst een grote impact zal hebben.
Een en ander blijkt uit een onderzoek van het Portugese OutSystems, specialist in low code-applicatieontwikkeling. ‘Techical debt’ wordt door OutSystems gedefinieerd als toepassingen en oplossingen die zijn gebouwd met het oog op een snelle levering, maar die uiteindelijk middelen opslokken, risico’s creëren en innovatie tegenhouden. Deze technologie is vooral gunstig op de korte termijn, maar brengt op lange termijn extra kosten met zich mee.
Bedrijven in alle sectoren en ongeacht hun omvang, betalen stevige alternatieve kosten omdat ze tijd, geld en middelen in technical debt steken in plaats van in innovatie, zegt OutSystems. Gemiddeld spenderen bedrijven ongeveer een derde van hun budget aan het aanpakken van technical debt. Er is geen eenduidige oorzaak voor technical debt, maar te veel ontwikkeltalen/frameworks (52 procent), verloop binnen het ontwikkelteam (49 procent) en het accepteren van bekende defecten om de release-deadlines te halen (43 procent), worden vaak genoemd.
Dikwijls blijken bedrijven de aanpak van technical debt uit te stellen, waardoor het probleem verergert. Slechts 20 procent zegt dat ze technical debt momenteel goed beheren. Iets meer dan een derde (36 procent) denkt hier in de toekomst toe in staat te zullen zijn. Technical debt wordt ook groter naarmate een bedrijf groeit. Grote ondernemingen besteden gemiddeld 41 procent van hun it-budget aan technical debt, kleine bedrijven 27 procent.
De bevindingen van het onderzoek zijn gebaseerd op een enquête uitgevoerd onder vijfhonderd it-professionals wereldwijd.
Ik ben eigenlijk wel nieuwschierig of er ook een verband is tussen de introductie van Agile werken en Technical Debt.
In enkele projecten waar ik in het verleden in gewerkt heb had ik meerdere malen het idee van “alles voor het halen van de sprint / sprint-demo”, waardoor er oplossingen geïntroduceerd werden waarvan je op je klompen aan kon voelen dat deze op termijn tot technical debt zouden leiden.
Betere oplossingen waren op zich wel voorhanden, maar omwille van het halen van de sprint goals enerzijds, maar ook keuzes vanuit de product owners anderzijds (nieuwe features zijn belangrijker dan het nu al weghalen van technical debt) werd hier zelden iets mee gedaan
Pa Va Ke: Helemaal met je eens. Agile werken is de motor achter technische schuld.
Een goede product owner kan inderdaad het verschil maken.
Wij werken agile en creëren continu een technische schuld. Hoe wij dit deels oplossen is dus met wat ik noem “refactor sprints”. Zo’n sprint bevat enerzijds (security) updates en upgrades naar (lts) versies van de diverse frameworks. Dit om te zorgen dat we niet te ver achterop raken. Anderzijds zijn het sprint items die niet functioneel zijn maar waarbij we de tijd nemen om de code te herschrijven zodat deze wat duurzamer is.
De filosofie daarachter is deze: “pre optimization is the root of all evil”
Soms weet je niet wat de beste oplossing is, of iets gewenst is, etc. Met Agile lever je snel iets op. En als het blijft plakken, dan refactoren we dat zodat het geen technische schuld oplevert.
Niettemin hebben ook wij gewoon een technische schuld die verder opbouwt. Dat is gewoon een fact of life als je software maakt.
On topic: Ook met low-code platformen heb je technische schuld. Zowel in het platform zelf als in de business apps die je ermee maakt. Het vergt lef en visie deze beheersbaar te houden.
“Het vergt lef en visie deze beheersbaar te houden.”
ja daarmee los je eigenlijk alles op, maar laat ik zeggen, niet iedere organisatie heeft lef en visie.
de stelling “pre optimization is the root of all evil” getuigt overigens wel van lef, maar lijkt me iets ongenuanceerd wat betreft visie.
wordt ook wat lastig als je organisatie groeit.
ik denk niet dat in pavs omgeving veel ruimte is voor refactoring. werk je in een groot bedrijf wat langer dan zie je het ook niet meer als debt, maar gewoon werk 😛
@Henri Koppen
Het is iets te snel door de bocht om Agile werken de beschuldigende vinger te wijzen. Het opbouwen van technical debt om een sprint goal te halen is prima, onder voorwaarde dat op de sprint backlog van de volgende sprint er een taak komt te staan (en blijft staan) die deze techncial debt oplost.
Let wel: een sprint-demo is precies dat: een demo, en inderdaad van iets wat in principe naar productie zou moeten kunnen. En omdat op de sprint backlog van de volgende sprint er een taak staat die deze technische debt aflost (en deze dus ook naar productie gaat) is er uiteindelijk geen probleem en toch is er Agile gewerkt.
Pa Va Ke legt echter de vinger op een van de zere plekken: functionele wijzigingen en toevoegingen krijgen vaak (zo niet vrijwel altijd) voorrang. De team heeft niet het laatste woord in dezen, waar het in theorie wel het geval zou moeten zijn.
Bij de sprint-retrospective moet de opgebouwde technische schuld worden benoemd, met de kosten daarvan op korte en lange termijn en de PO moet begrijpen wat dit inhoudt en de inschatting van de teamleden die dit aandragen en duidelijk maken respecteren.
Echter, in werkelijkheid is er boven de PO een heel leger van managers die roepen “Het werkt toch? Nou, daar gaan we geen geld meer in stoppen… deze nieuwe/gewijzigde functionaliteit is veel belangrijker!”. Deze managers hebben vaak geen enkel besef van technische schuld of uberhaupt belang in langer termijn visie. Hun KPI is al lange termijn (waar “lang” in deze gevallen vaak niet langer is dan 3 maanden).
Het probleem is zo vaak niet de methode of methodologie, maar de manier waarop deze in de organisatie is ingebed, of in deze gevallen niet in de organisatie is ingebed, maar beschouwd wordt als zuiver een IT-feestje.
Let wel: er zijn organisatieleiders die wel zien dat Agile alleen gaat werken als de hele organisatie mee beweegt. Maar lang niet alle managers zijn organisatieleiders.
@CPR: reden dat ik naar agile wees is vooral gebaseerd op eigen ervaringen. Mijn ervaring met waterval projecten is dat daar vooraf al een stuk beter nagedacht werd over het totale eindplaatje, en dat dit meegenomen werd in initiële implementatie- en designkeuzes waardoor er minder technical debt in het eindproduct zat
Maar ook daar gold wat jjj schets: een leger managers dat roept “maar het werkt toch”; dus waarom zou ik upgraden naar (bijvoorbeeld) die nieuwe windows versie? Aan nieuwe features kunnen we meer verdienen
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back prompty. The danger occurs when the debt is not repaid. Entire engineering organisations can brought to a standstill under this debt.” -Ward Cunningham
Het gaat Ward Cunningham dus om het rendement op de code wat een heerlijk angelsaksische benadering is van het probleem, money talks! Daarmee heb ik een vraag voor Henry aangaande de cost accounting van agile als het om poetsen van knikkers of parels gaat. Mogelijk een wat cryptische vraag maar Dino is van de herbruikbare code en ik van het spel om tot oplossingen te komen die zowel beheer- als beheersbaar zijn want knikkers en parels rollen beiden.
Ik weet wat de kalkoen wil en of vijfhonderd respondenten op een vragenlijst echt iets zinnigs over de bedrijfseconomische keuzen zeggen is twijfelachtig want hoeveel geld moet je als (non)engineering organisatie steken in onderhoud op maatwerk waar steeds minder vraag naar is, zeg maar het verkeerde paard waarop gewed is omdat de adoptie van de markt om een andere standaard gaat.
Om Agile produkten los te zien van de complete software stack (context) waarop eea. draait: hardware, virtualisatie, runtime omgevingen OS, Java, applicatieservers, (low-code draait ook in een runtime omgeving), software en package dependencies etc. is als het kijken met oogkleppen op naar een eindproduct. Mooie nieuwe applicatie, maar hoelang blijft alles even goed draaien (met dezelfde functionaliteit en performance)? De grootte van de software stack (van hardware tot applicatie niveau) is hier vrij bepalend.