De wall of technical debt: maakt techdebt visueel

De wall of technical debt

Technical debt kan voor organisaties een forse belemmering zijn bij het bereiken van hun doelen. Het is een term die bij softwareontwikkeling wordt gebruikt en is te omschrijven als het resultaat van verkeerde beslissingen in het verleden, vaak vanwege het prioriteren van een snelle oplevering ten opzichte van de perfecte code. Soms ontstaat technical debt ook omdat best practices van vroeger worden achterhaald. Technical debt is niet per definitie slecht. Soms is het snel uitbrengen van een nieuwe feature belangrijker dan de onderhoudbaarheid van de code.

Wendbaarheid

De prijs van technical debt betaal je altijd in tijd. Wanneer organisaties onvoldoende tijd besteden aan het wegwerken van technical debt kan die prijs zo hoog worden dat het doorontwikkelen van software onredelijk lang gaat duren. Dit heeft tot gevolg dat organisaties minder wendbaar worden. Ze kunnen hierdoor minder snel reageren op veranderingen in de markt, waardoor ze achterop raken ten opzichte van de concurrentie. Het grote probleem van technical debt is dat het vaak onzichtbaar is. Developers kunnen vaak wel aangeven dat de technical debt bestaat, maar vinden het moeilijk om er een echte kosten-/batenanalyse van te maken. De wall of technical debt is een hulpmiddel dat kan helpen om deze analyse te maken.

De wall of technical debt is een idee van Mattias Verraes.

Het doel van de wall of technical debt is:

1. Technical debt visueel maken
2. Een kostenplaatje berekenen voor ieder stukje technical debt

Het is een verrassend simpel concept waarbij je een bord gebruikt waarop iedereen sticky notes kan plakken met zaken waardoor tijd verloren is gegaan. Het hoeven niet per se zaken te zijn die direct gerelateerd zijn aan code. Alles wat ervoor zorgde dat jij als developer vertraging opliep is valide: gebrek aan documentatie, incomplete tests of een vreemde bug die alleen voorkomt op 31 februari.

Stippen op sticky notes

Daarnaast is het van belang te noteren hoe veel tijd er verloren is gegaan. Dit betreft tijd die besteed had kunnen worden aan het implementeren van andere software als dit stukje technical debt niet op je pad was beland. Verraes benadrukt in zijn uitleg dat het belangrijk is om als team een eigen meeteenheid af te spreken voor tijd. Een enkele stip op de sticky note zou bijvoorbeeld kunnen staan voor een halve dag verloren tijd. Zo wordt ieder stukje technical debt visueel.

Naast een omschrijving heeft het nu ook een kostprijs. Deze kostprijs zou interessant moeten zijn voor iedereen binnen een organisatie die belang heeft bij snelle softwareontwikkeling. Het oplossen van technical debt heeft een concrete opbrengst in de vorm van tijd. Teamgenoten die tijd verliezen aan dezelfde issues kunnen hun stippen toevoegen aan bestaande sticky notes.

Meten van verloren tijd maakt technical debt objectiefHet belangrijkste voordeel van het meten van verloren tijd is dat het technical debt objectief maakt. Een stuk software kan gebouwd zijn op de meest vreselijke manier, wat doorontwikkelen bemoeilijkt. Maar als er praktisch nooit iets aan hoeft te worden veranderd, is het dan wel daadwerkelijk technical debt? Dergelijke zaken krijgen terecht geen aandacht op de wall, omdat ze niet relevant zijn.

De andere helft van de formule

Met het berekenen van de opbrengsten hebben we echter nog maar de helft van de formule opgelost. De andere helft betreft het schatten van de kosten voor het oplossen van technical debt. Door een inschatting te maken van de inspanning die het kost, wordt het mogelijk een kosten-/batenanalyse te maken. Het inschatten van wijzigingen aan software is nooit exacte wetenschap, dus helemaal kloppend zal je schatting niet zijn. Toch wordt het evident dat het oplossen van bepaalde technical debt makkelijk een investering rechtvaardigt:

De afgelopen vier weken hebben X en Y gewerkt aan een nieuwe feature voor hun organisatie. Daarbij liepen zij tegen technical debt aan. Na vier weken staan er acht stippen (iedere stip is een halve dag werk) op de sticky note. Tijdens het ontwikkelen van de feature is er dus vier dagen aan tijd verloren gegaan. X heeft geschat dat het oplossen van de technical debt ongeveer twee dagen in beslag gaat nemen. X en Y leggen de situatie voor aan de product owner. Zij willen graag weten of op de roadmap nog veel werk gepland staat in hetzelfde domein als waar de technical debt gevonden is. De product owner geeft aan dat dit het geval is.

Een simpele berekening leert hen dat de investering zich snel terug zal betalen:

• Verwacht werk in domein: 12 weken
• Verwacht tijdverlies: 24 stippen (12 dagen)
• Verwachte tijdsinvestering oplossing: 2 dagen

12 dagen - 2 dagen = 10 dagen aan tijd gewonnen.

Een impact/effort-matrix kan helpen om de prioriteit van de technicaldebt-issues te bepalen.

BHet is gereedschap om mee te overtuigen van de noodzaak om technical debt weg te werkenovenstaand voorbeeld is een illustratie van hoe technical debt door de wall of technical debt onderhandelbaar wordt. Het wordt op deze manier makkelijk om technicaldebt-issues op waarde te schatten. In zijn algemeenheid zijn issues die veel impact hebben maar relatief weinig moeite kosten de beste kandidaten om op te lossen (zie impact/effort-matrix). Product owners of andere stakeholders binnen een organisatie kunnen op deze manier kennisnemen van de belemmeringen die developers hebben tijdens de uitvoering van hun werk. Dit is de verantwoordelijkheid van de developers zelf. Als professional is het je verantwoordelijkheid om de juiste keuzes te maken voor de organisatie waarvoor je werkt. Zowel op de korte als lange termijn. De wall of technical debt geeft je een stuk gereedschap om belanghebbenden te overtuigen van de noodzaak om technical debt weg te werken.

Bij Tweakers hebben we vlak voor de lockdown in maart besloten een wall of technical debt te introduceren. Nog voordat we daadwerkelijk een bord hadden ingericht moesten we plotseling allemaal gaan thuiswerken. In eerste instantie hebben we een digitale variant gemaakt in een Google Sheet. Het bord verliest dan echter een belangrijke functie: de zichtbaarheid. Op dit moment werken we aan een verbeterde digitale variant die we kunnen inzetten tot we weer veilig naar het kantoor kunnen.

Digitale variant van de wall of tech debt bij Tweakers. Nog volop in ontwikkeling.

Feedback

Dit artikel is een van meerdere die we door ontwikkelaars, voor softwareontwikkelaars willen publiceren. Inhoudelijk kun je onder dit artikel reageren, maar heb je andere feedback op dit artikel of ideeën over komende artikelen, dan kun je die in dit topic achterlaten.

Reacties (135)

[Lordsauron]

Ik heb nu al een paar keer voorbij zien komen dat meneer Mattias Verraes dit bedacht zou hebben, in 2018 gebruikte wij dit al in ons bedrijf en na wat zoeken vond ik dan toch dit: http://fabiopereira.me/bl...nical-debt-retrospective/

[AcidBanger]

https://refactoring.guru/refactoring/technical-debt

Deze meneer heeft het ook al zeer lang over dit topic.

[David Mulder]

Het gaat om het idee van "wall of" niet de technical debt zelf.

[AcidBanger]

was weer te enthousiast met reageren had dit stukje toevallig net gelezen voordat ik dit artikel zag.

[jeffreytigch]

Toen ik op de middelbare school voor Duits een werkstukje moesten inleveren over een bepaald onderwerp, werd ik een dag na inleveren op het matje geroepen, samen met een andere mede-student. Wij werden beide beschuldigd van plagiaat, omdat onze werkstukken zo op elkaar leken.

Bleek dat we de inspiratie haalde uit dezelfde bronnen. Blijkt maar weer: meerdere mensen kunnen individueel tot dezelfde conclusie of uitkomst komen.

[Verwijderd]

Klein verschil: in jouw voorbeeld publiceerden jullie het tegelijkertijd.
Hier zit 11 jaar tussen...

[Verwijderd]

En als Mattias in al die jaren bedenken een keer had gegoogled....

Kom aan tweakers, correctie!

[tijmenwierenga]

Het artikel van Verraes verwijst naar een eerder door hem artikel geschreven uit 2013 (wat uiteraard ook nog ver na 2009 is). Ik zal het in ieder geval even verder uitzoeken en eventueel rectificeren.

[Q]

Is Technical Debt niet stiekem een beetje een bullshit term?

Technical debt impliceert dat er ooit een bewuste keuze is gemaakt om nu snel een feature op te leveren met brakke code om op een later moment die lening terug te betalen, dus om die brakke code door goede code te vervangen.

Hoe vaak gebeurt dit werkelijk in de praktijk?
Hoe vaak wordt deze keuze heel bewust genomen in samenspraak met de business?

Mijn indruk is dat Technical Debt te pas en te on pas - mede op basis van wat ik van andere mensen hoor - wordt gebruikt om verantwoordelijkheid voor code te ontlopen. We geven niet toe dat we 'destijds' gewoon slechte code hebben opgeleverd, we noemen het 'technical debt'.

En met 'Technical debt' is de kous af. Niemand gaat dan verder moeilijke vragen stellen.

Moeilijke vragen zoals: hoe kan het dat we met elkaar slechte code opleveren? Wat gaat er mis in ons design proces? Wat gaat er mis in ons ontwikkelproces? Hoe zouden we dat kunnen verbeteren?

Soms ontstaat technical debt ook omdat best practises van vroeger worden achterhaald. Technical debt is niet per definitie slecht.

Ik vind dit helemaal geen technical debt. Het is puur dat de wereld veranderd en of je kunt er makkelijk in mee, of niet omdat het design dit niet makkelijk toestaat.

Dat maakt een design niet slecht, maar slechts niet geschikt voor nieuwe requirements die je toen nog niet kende en niet kon voorzien.

Maar waarom zouden we dan een andere term gebruiken? Waarom zouden we gewoon niet kunnen zeggen dat het design niet geschikt is om de nieuwe requirements te faciliteren? En dat je daar dan gewoon iets mee gaat doen?

P.S. ik vind het leuk dat er eens een keertje een professioneler artikel wordt gepost, erg gemist hier op Tweakers.

[Reactie gewijzigd door Q op 22 juli 2024 21:26]

[P_Tingen]

Wat mij betreft is het niet noodzakelijkerwijs altijd slechte code. Volgens mij kan technical debt op verschillende manieren ontstaan:

1) Slecht werk in het verleden waar te lang al op is doorgeborduurd. Dit kan slechte code zijn maar ook het nalaten van documenteren of het maken van testcases
2) Een bewuste keuze om snel iets te kunnen maken. Dit kan zijn vanwege concurrentievoordeel maar ook omdat er een urgent probleem moet worden opgelost
3) Voortschrijdende techniek. Je plugin of framework van 5 jaar terug is achteraf toch niet zo toekomstbestendig gebleken. Of je OS ondersteunt bepaalde dingen in je applicatie niet meer of dwingt juist nieuwe dingen af (denk aan opt-in voor tracking op iOs)

De discussie over wat precies technical debt is, is nog niet eens zo eenvoudig. Ik luister veel naar de podcast maintainable waarin elke gast zo ongeveer een nét iets andere definitie hanteert van wat het is.

[Jantimon]

4) Voortschrijdend inzicht - feature A moet worden uitgebreid. Feature B en C hebben veel overlap en moeten worden samengevoegd. Feature D wordt niet meer gebruikt. Dat soort zaken.

[SPee]

Je vergeet:
4) Oude collega's gaan weg en nieuwe komen ervoor in de plaats. Die krijgen niet altijd alle historie van het project mee.
5) niet iedereen is even competent.

[Q]

1) Slechte code
2) Ongeteste code / prototype / Critische Bugfix
3) Onderhoud (lifecycle)

Ik zie eigenlijk gewoon geen plek voor de term 'Technical Debt'. Kent enige andere serieuze professie deze term? DAt maintainable weer een andere definitie hanteert is ook al opvallend. (tnx voor de link).

Als je sneller bent door brakke code op te leveren dan gewoon netjes iets te bouwen zoals je het normaal doet, is er dan niet iets heel erg mis?

Ik heb het niet over test coverage maar puur de code zelf.

[Reactie gewijzigd door Q op 22 juli 2024 21:26]

[Gomez12]

1) Slechte code
2) Ongeteste code / prototype / Critische Bugfix
3) Onderhoud (lifecycle)

Ik zie eigenlijk gewoon geen plek voor de term 'Technical Debt'. Kent enige andere serieuze professie deze term? DAt maintainable weer een andere definitie hanteert is ook al opvallend. (tnx voor de link).

Het probleem is dat je punt 1 grotendeels al Technical Debt is, puur vanwege het feit dat de ideeen over goed en slecht veranderen door de tijd heen.

Een php1.0 script zal nu als slecht gezien worden.
Of JS is ook zoiets leuks, het is heel lang good practice geweest om plain JS te programmeren, toen werd het complexer vanwege verschillende browsers etc en toen werd jquery etc good practice om te gebruiken, nu volgen de browsers elkaar grotendeels weer en is het weer good practice om in plain JS te programmeren.

Je zou kunnen zeggen dat dit valt onder onderhoud, maar waarom iets vervangen wat gewoon goed werkt?

Een leuk buiten IT-voorbeeld is wmb dan ook iets als asbest. Je kan het in heel NL overal uit gaan halen (/heel NL onderhouden) of je kan bij elke verbouwing weer tegen Technical Debt aanlopen als je asbest tegenkomt.
Vroeger was het gewoon goed materiaal om mee te isoleren, tegenwoordig is het een bad-practice / verboden om nog te gebruiken. Terwijl er aan de asbest/code niets is veranderd is het toch Technical Debt geworden...

[Q]

Nee, slecht geschreven code is niet meer dan dat: 'slechte code'. Dat heeft niets met TD te maken.

Als ieeen over goed en slecht veranderen - wat ik erg hard betwijfel - dan was je code op het moment van schrijven dus gewoon goed, dus nam je geen 'debt', of wat dat ook mat betekenen.

Als de requirements of inzichten veranderen over hoe zaken beter kunnen, dat is gewoon evolutie van kennis. En het is niet zozeer 'slecht' als in: vaak is een nieuwe methode wat efficienter, of makkelijker te onderhouden, maar het is niet absoluut slecht en onbruikbaar opeens.

Je voorbeeld van PHP1 heeft ook niets met code kwaliteit te maken. Code in PHP1 geschreven kan gewoon prima robuust zijn en aan de requirements voldoen. Dat je nog PHP1 draait is meer een liability qua security en support, maar dat heeft alles met onderhoud te maken en lifecycle management. Dit is geen TD.

JA het is onderhoud omdat het toepassen van security patches essentieel kan zijn om niet gehacked te worden. Maar als het intern achter een paar firewalls draait, tja, who cares. Maar dan is het slechts achterstallig onderhoud dus ja dat is het. Achterstallig onderhoud. Maar wederom niets te maken met TD.

En asbest is ook geen "Technical Debt" want er is nergens bewust de keuze gemaakt om een shortcut te nemen door overal asbest toe te passen terwijl we wisten dat het dodelijk was. Pas veel later bleek uit onderzoek dat het extreem gevaarlijk is.

Asbest is geen 'Technical debt'. Asbest is gewoon een foute keuze geweest. Een hele vervelende foute keuze die veel schade heeft veroorzaakt, maar het is geen voorbeeld van TD.

De definitie van TD is niet keuze X die op dat moment goed leek maar later niet zo bleek te zijn. Dat is niets meer dan voortschrijdent inzicht, kan gebeuren, helaasl soms met ernstige gevolgen.

Maar TD wordt altijd omschreven als bewust een keuze maken om iets 'goors' te doen om op korte termijn een business doel te halen. Om dan bewust later een moment te pakken om die gore troep weg te gooien en 'netjes' te implementeren. En dat was helemaal niet het geval met Asbest.

[Gomez12]

Je voorbeeld van PHP1 heeft ook niets met code kwaliteit te maken. Code in PHP1 geschreven kan gewoon prima robuust zijn en aan de requirements voldoen.

Alhoewel het theoretisch zou kunnen, zal er in de praktijk 0.0 PHP1 code bestaan die aan hedendaagse requirements voldoet. En de code zal prima robuust zijn.
Alleen als men het tegenkomt dan zal het aan hedendaagse requirements aangepast moeten worden, dat is ook gewoon TD.

Maar TD wordt altijd omschreven als bewust een keuze maken om iets 'goors' te doen om op korte termijn een business doel te halen. Om dan bewust later een moment te pakken om die gore troep weg te gooien en 'netjes' te implementeren. En dat was helemaal niet het geval met Asbest.

Het probleem hier is dat vooral jij vindt dat TD altijd zo omschreven wordt, ik zie hier alleen al in de comments mensen die het "altijd" niet onderschrijven. Het artikel omschrijft het niet zo.

Oftewel gaat je vraag over "TD" of over "TD volgens Q"? Want van die 2e heb ik geen kennis.

[Q]

Alhoewel het theoretisch zou kunnen, zal er in de praktijk 0.0 PHP1 code bestaan die aan hedendaagse requirements voldoet. En de code zal prima robuust zijn.

Hedendaagse requirements? Nee dat kan niet want die kenden we 'toen' niet. Dus als requirements veranderen dan zijn dus seq de requirements veranderd, maar dat is geen TD.

Alhoewel het theoretisch zou kunnen, zal er in de praktijk 0.0 PHP1 code bestaan die aan hedendaagse requirements voldoet. En de code zal prima robuust zijn.

Veranderende requirements TD noemen vind ik echt niet ok, dat slaat wat mij betreft helemaal nergens op. Dan verwatert het begrip TD tot iets betekenisloos, straks gaan we iedere bug TD noemen.

TD wordt altijd omschreven als nu iets goors opleveren om het op een later moment netjes te doen. Dat heeft niets met veranderende requirements te maken.

[Gomez12]

[...]
Hedendaagse requirements? Nee dat kan niet want die kenden we 'toen' niet. Dus als requirements veranderen dan zijn dus seq de requirements veranderd, maar dat is geen TD.

Dat is dus juist wel TD. Om het even bij het php1.0 example te houden, dat was puur opgezet als scripting language waarbij je gewoon midden in je html kon plempen <? echo "hello world" ?>.
Tegenwoordig is het vanwege grotere html en grotere php-code een "requirement" dat je je html en je code scheidt. Oftewel die <? echo "hello world" ?> die middenin je html geplempt staat in een aantal bestandjes die compiled nog wel, alleen voldoet niet meer aan de requirements van nette php.

Dan zou je op het moment dat die requirement aangepast wordt dus of het hele project vanaf nul kunnen gaan doorlopen en daarbij dus een heleboel onbetaald werk verrichten.
En dat is dus leuk als je een projectje hebt van 3 dagen. Maar als je gewoon een al jaren lopend project hebt dan is dat geen optie.

Of je besluit gericht de grootste pijnpunten aan te pakken, de nieuwe code volgens de nieuwe requirements te doen en dan simpelweg te accepteren dat je in de toekomst op sommige punten extra tijd kwijt gaat zijn vanwege dat er ergens nog html en php-code vermengd is wat je op het moment dat je het tegenkomt moet gaan splitsen.

Dat is dus juist ook TD.

[...]
TD wordt altijd omschreven als nu iets goors opleveren om het op een later moment netjes te doen.

Nogmaals dat is enkel jouw definitie van TD, dat is niet een algemene definitie van TD.

Of laat ik het eens met een ander voorbeeld proberen : Stel dat je een giga-muur vol met schilderijtjes moet hangen en je weet dat je altijd enkele schilderijtjes zal moeten vervangen.
Dan begin je met het ophangen met dubbelzijdig plakband.
Maar na een half-jaar komt er een rail bovenaan die muur waarvandaan je de schilderijtjes kunt ophangen aan een touwtje wat veel makkelijker is.
Ga je nu die 1e half jaar opnieuw doen zodat alles aan een touwtje hangt? Of ga je gewoon vanaf heden het touwtje gebruiken want dat is makkelijker en als je dan een oud schilderijtje moet vervangen dan ben je gewoon een uur langer bezig om de plakband van het schilderij en de muur te schrapen maar vanaf dan hangt het wel aan een touwtje...

Dat is dus juist TD, zolang de rail er niet hangt is dubbelzijdig plakband een goede oplossing, maar als de rail er hangt dan is dubbelzijdig plakband "goor". Alleen de klant maakt het niets uit en die betaalt niet voor het vervangen van oud goed door nieuw goed.
En nee, je kon niet aan het begin voorstellen om een rail op te hangen, want die bestond toen simpelweg nog niet.

[Q]

Of je besluit gericht de grootste pijnpunten aan te pakken, de nieuwe code volgens de nieuwe requirements te doen en dan simpelweg te accepteren dat je in de toekomst op sommige punten extra tijd kwijt gaat zijn vanwege dat er ergens nog html en php-code vermengd is wat je op het moment dat je het tegenkomt moet gaan splitsen.

Dat is dus juist ook TD.

Nee, dat is geen TD.

Als requirements veranderen dan is dat gewoon een nieuwe situatie waar je mee om moet gaan. En je kunt dat op heel veel verschillende manieren aanpakken. Maar nergens in het proces is heel bewust een soort keuze gemaakt om een 'debt' aan te gaan om die later terug te betalen.

Het is puur dat de requirements zijn veranderd en dat je daarmee moet omgaan. Meer niet.

Nogmaals dat is enkel jouw definitie van TD, dat is niet een algemene definitie van TD.

Wat is volgens jou dan de algemene definitie van TD en wat is jouw bron daarvoor? Ik probeer het even uit een welles-nietes-discussie te halen die hier lijkt te ontstaan.

Schilderijtjes voorbeeld

Vanaf heden ga je nieuwe schilderijen aan een touwtje ophangen en oude schilderijen laat je hangen. Als je een oud schilderij wilt vervangen dan moet je eerst plakband lostrekken wat x tijd kost (meer dan van touwtje halen) maar die extra effort is geen TD en anders mag jij uileggen waarom dat wel TD zou moeten zijn en volgens welke definitie van TD jij dat dan TD noemt.

Dat een oudere oplossing minder efficient is, is geen definitie van TD, hooguit 'legacy'. Maar IT en software ontwikkeling is altijd een proces van continue verbetering en vernieuwing en verandering (als in neutraal: het is anders maar niet beter of slechter).

Ik krijg het gevoel dat jij een definitie van TD hanteert waarbij eigenlijk per definitie de code/oplossing van gister al weer TD is geworden. Dat vind ik waanzinnig.

Kortom, wat mij betreft weer een voorbeeld wat NIETS met TD te maken heeft. Er komt een nieuwe optie en je gaat die nieuwe optie gebruiken omdat die 'beter' is maar de oude optie is niet verkeerd dus je hoeft niets uit te faseren dan op een natuurlijke manier conform een levenscyclus.

Wat je hier beschrijft is puur lifecycle management. Dat is al een oudere term die bestaat. Het touwtje is de nieuw oplossing, plakband is legacy en wordt gewoon netjes uitgefaseerd.

Je schiet jezelf erg in de voet met dit soort analogieën. In mijn ogen maak je in feite mijn punt. Dus bedankt daarvoor.

[Reactie gewijzigd door Q op 22 juli 2024 21:26]

[P_Tingen]

Als je sneller bent door brakke code op te leveren dan gewoon netjes iets te bouwen zoals je het normaal doet, is er dan niet iets heel erg mis?

Als je de code netjes maakt en je bent vervolgens te laat omdat je concurrent de markt heeft ingepikt, is er dan niet iets mis?

Ik bedoel maar: er kunnen legitieme redenen zijn om quick and dirty iets op te leveren. Kijk naar Microsoft, die waren nooit zover gekomen als ze hun eerste DOS versie helemaal uitgekristalliseerd hadden.

[Q]

Als je de code netjes maakt en je bent vervolgens te laat omdat je concurrent de markt heeft ingepikt, is er dan niet iets mis?

Hoe vaak gebeurt dit in de praktijk en hoe vaak is dat ook echt de juiste business keuze?

Ik bedoel 'netjes' hier boven niet in de trand van 'nette code' (perfectionisme) maar als in 'conform de normale manier van werken (processen)).

Waarom zouden we alle processen overboord moeten gooien met alle risico's van dien om iets op te leveren, zeker als dat internet-facing en hackbaar is?

Als het echt zo belangrijk is, draai maar overuren, als de businesscase dat niet waard is, dan heb je denk ik geen business case.

Als je de bocht moet gaan afsnijden op deze manier, dan heb je denk ik best wel problemen.
Want als je in een soort business zit dat je zo ontzettend snel moet reageren, dan moet je platform er ook op ontworpen zijn, dit kan niet zomaar eenmalig uit de lucht vallen.

En als het eenmalig uit de lucht valt (stel), dan is dat meer een incident terwijl de indruk wordt gewekt dat je technical debt continue op allerlei vlakken opbouwt. (Waar ik het niet mee eens ben).

[Reactie gewijzigd door Q op 22 juli 2024 21:26]

[J_van_Ekris]

Ik zie eigenlijk gewoon geen plek voor de term 'Technical Debt'. Kent enige andere serieuze professie deze term?

Achterstallig onderhoud. De infrastructuur van menig zuid-europees land, en de VS kampen er structureel mee.

[Q]

Prima, laten we gewoon die term gebruiken die de rest van de wereld ook gewoon snapt

[Full_hyperion]

[...]

Ik vind dit helemaal geen technical debt. Het is puur dat de wereld veranderd en of je kunt er makkelijk in mee, of niet omdat het design dit niet makkelijk toestaat.

Op het moment dat die code geschreven wordt, is het natuurlijk geen technical debt, want het volgde toen netjes de best practices.
Maar als later blijkt dat die code niet meer geschikt is, sta je voor een keuze: pas je de code aan zodat het weer mee kan met de veranderende wereld, of neem je een lening op die code door het aanpassen uit te stellen.
En die 2e optie kan ook heel makkelijk impliciet gebeuren door er even niet bij stil te staan, en het probleem gewoon te negeren en er omheen te werken.

[Q]

Een lening neem je bewust. Dus ik ga sowieso niet mee in analogieen waarbij mensen 'onbewust' leningen aan gaan.

Ik blijk een lening van 50.000 euro aan te zijn gegaan vorige maand, maar ik wist van niets?
Dat vind ik echt een onzin, zo gaat dat niet. Als dat wel gebeurt gaat er iets heel erg mis maar met Technical Debt (wat het ook mag zijn) heeft het niets te maken.

Als het design van een code-base niet meer (voldoende) geschikt is voor de veranderende behoeften dan sta je inderdaad voor een keuze.

Ook hier is trouwens de strikvraag; hoe vaak gebeurt dit werkelijk in de praktijk? Want laten we wel wezen, dat zou feitelijk inhouden dat de business (en bijbehorende processen) zelf fors zijn veranderd.

Dat impliceert dat je eingelijk niet eens een keuze hebt, je moet gewoon mee met de verandering. Doorgaan met de huidige architectuur is niet eens een optie in die context. Daarmee doorgaan is geen Technical debt, dat zou gewoon simpelweg een 'verkeerde keuze' zijn.

Maar als het allemaal niet zo extreem is: de architectuur is niet zo geschikt maar we kunnen verder, dan bouw je geen debt op. Je kunt een schip niet zomaar even van koers veranderen.

Je lapt een schip voldoende op om het drijvende en operationeel te houden, totdat het nieuwe schip af is. En dat vind ik geen technical debt, dat is gewoon een 'tactiek' om je business te laten overleven.

[J_van_Ekris]

Een schuld kan natuurlijk ongemerkt oplopen, bijvoorbeeld door ongemerkt rood staan. En dat gebeurt hier natuurlijk ook.

En soms is het bewust: men kiest ervoor om snel met iets in productie te willen, maar vergeet daarna de code op te poetsen.

[Q]

Ik ben zelf geen software ontwikkelaar, maar een vriend van mij wel. Hij heeft nog nooit meegemaakt dat hij met allemaal shortcuts en prutscode live moest om een business doel te halen.

Mijn punt is een beetje: ik heb sterk het gevoel dat dit scenario - wat te pas en te onpas te berde wordt gebracht - helemaal niet zo realistisch is. Dat hele scenario van bewust shortcuts nemen en die debt terug betalen is gewoon in de praktijk helemaal geen serieus scenario.

Maar stel nu dat het wel wordt gedaan: dan is het puur een busineses evaluatie: nu snel pruts code online flikkeren en hopen dat het waarde oplevert en dat we niet keihard ge p0wned worden of het hele platform mee het riool in wordt getrokken. Maar dat is echt waanzin, wat mij betreft.

Het concept van schuld en dat terug betalen is iets wat gewoon in mijn ogen geen ding is. Je hebt gewoon goede code of slechte code. Of code die goed was maar omdat de requirements zijn veranderd is deze code niet meer relevant en daar moet je dan wat mee.

[J_van_Ekris]

Ik ben zelf geen software ontwikkelaar, maar een vriend van mij wel. Hij heeft nog nooit meegemaakt dat hij met allemaal shortcuts en prutscode live moest om een business doel te halen.

Dan heeft jouw vriend een hele boel geluk gehad. Ik zit 25 jaar in de IT, vaak om projecten te redden als ze dreigen te mislukken, en dan heb je links en rechts wel wat ellende weg te poetsen....

[Q]

Hij zit 18 jaar in de IT, dus nog 7 jaar op achterstand. Maar ik heb altijd erg veel vragen in die contexten.

- hoe realistisch is de druk
- hoe ernstig is het werkelijk als een paar features niet geleverd worden
- hoe kan het dat shit code in deze context acceptabel is
- waarom zou het over een paar maanden opeens wel okee zijn om tijd te besteden om de shit code te fixen, wat is hier de context.
- ik kan zo door blijven gaan. Ik durf de weddenschap wel aan dat in veel situaties andere keuzes zeker een optie waren geweest.

Kortom, ik ken jouw context niet maar op basis alleen al van mijn eigen werkervaring (sysadmin/ops) heb ik vaak het gevoel dat dit soort situaties nergens voor nodig zijn. Maar dat ben ik, schipper aan wal, dat geef ik toe.

Begrijp me niet verkeerd, ik wil je hiermee niet aanvallen/bekritiseren.

Maar keer op keer is dit mijn ervaring: ik hoor drama verhalen van persoon X en moeilijk moeilijk Z kan echt niet. Maar dan ga ik zelf met persoon Y praten die voor Z verantwoordelijk is, en dan hebben we een vriendelijk professioneel gesprek, waar ik me vaak ook 'kwetsbaar / kaarten op tafel' in ga, en met Y dan tot een oplossing komt en dan blijkt Z geen probleem om te realiseren.

Keer op keer op keer op keer op keer.

[Gomez12]

Ik ben zelf geen software ontwikkelaar, maar een vriend van mij wel. Hij heeft nog nooit meegemaakt dat hij met allemaal shortcuts en prutscode live moest om een business doel te halen.

2 Mogelijkheden :
- Of die vriend van jou heeft nog nooit van zijn leven een deadline gekregen.
- Of die vriend van jou hangt er andere termen aan zoals jij ook lijkt te willen doen.

[Q]

Deadlines zijn in erg veel gevallen onderhandelbaar, maar veel mensen realiseren zich dat niet. Mensen laten zich gek maken door kunstmatige druk, houden hun hoofd niet koel en laten zich pushen om 'stomme dingen' te doen. Dat hoeft niet aan de hand te zijn hoor, ik wil niemand beschuldigen, maar ik ben ook zo geweest en ik heb hard geleerd.

Voor wat termen betreft: ik zie het andersom, mensen hebben de term technical debt bedacht omdat het goed klinkt maar in feite niets toevoegd aan begripsvorming en verdoezeld wat er vaak aan de hand is: er is gewoon slechte code opgeleverd, of de requirements zijn veranderd.

Overigens heeft die vriend zijn schaapjes op het droge als je snapt wat ik bedoel, ik durf te wedden dat er maar weinig mensen hier zijn in de discussie die dat ook kunnen zeggen. Hij is erg effectief.

Maar weet je: ik ben skeptisch maar misschien zijn er oprecht cases die je werkelijk zou kunnen omschrijven als een voorbeeld van technical debt.

Ik durf te wedden dat daar in extreem veel gevallen heel veel voorbeelden tegenover staan die ook als TD worden bestempeld maar het niet zijn. Daar wordt TD gewoon gebruikt als een magisch schild dat mensen afschermt voor iedere en alle verantwoordelijkheid.

- Slechte code is geen TD
- Veranderende requirements is geen TD

[Gomez12]

- Slechte code is geen TD

Ok, laat ik de vraag eens omdraaien dan? Wat is slechte code?
Of : Is code slecht als het doet waarvoor het geschreven is?

Een gedeelte van nu "slechte" code is bijv ook geschreven in tijden dat de hardware minder was en dat bijv 1 extra abstractie laag simpelweg een seconde wachten toevoegde, heden ten dage is de hardware zo sterk dat je een miljoen abstractie lagen kan toevoegen en nog wacht je geen seconde.
Is het nu opeens slecht als je in oude code iets aantreft wat niet naar de hedendaagse standaard geabstraheerd is?
Want het gaat je wel extra tijd kosten om die oude code naar de hedendaagse abstracties te krijgen en die tijd noemt men dus TD, maar de code is nooit echt fout geweest... Alleen wordt nu gezien alszijnde slecht.

- Veranderende requirements is geen TD

Niet als het veranderende requirements vanuit de klant zijn, alleen kunnen ook andere partijen (waaronder je eigen bedrijf) de requirements veranderen waardoor je dus of onbetaald een gedeelte van het werk opnieuw mag doen of je dus TD kan creeeren.

[Q]

Ik zie eigenlijk geen nut in verdere discussie totdat jij duidelijk een heldere definitie geeft van wat jij TD noemt.

Je voorbeeld hier is wederom gewoon een verhaal van gewijzigde omstandigheden waar je je aan moet aanpassen, wat heel gebruikelijk is in iedere business en dat heeft wat mij betreft helemaal niets te maken met wat veel mensen TD noemen.

Dus ik wacht op jouw heldere definitie.

[Gomez12]

Schuld ontstaan door techniek, of dat nu veranderend of in 1e instantie slecht gebruik is dat is irrelevant.

[Q]

Dit slaat helemaal nergens op en je hebt geen definitie gegeven, einde gesprek.

[DeeD2k2]

Eens met je punt over goede en slechte code. Technical debt is geen excuus om slechte code te mogen leveren.
Technical debt aanvaarden is wel een manier om business doelen te behalen door sub-optimale oplossingen te maken. Dat wil voor mij zeggen dat je goede code schrijft om een technisch niet courante oplossing te maken.

Denk hierbij aan een stuk programmatuur dat niet voldoet aan je architectuur principes of beheer eisen. Ik heb bijvoorbeeld vaker meegemaakt dat om een business deadline (voor migratie, facturatie, transitie etc) te halen snel een keuze menuutje toegevoegd is en deze pas in een latere iteratie netjes aan de beheer module gekoppeld is.

Nette code, "slechte" oplossing...

[DeeD2k2]

Volgens mij zegt ook niemand dat technical debt een synoniem is voor werk dat af is.
De introductie van technical debt maakt het voor een ontwikkel team mogelijk om een iteratie op te leveren waarbij het resultaat niet voldoet aan de afgesproken standaarden maar wel aan de business doelstellingen.

Hier zitten een aantal randvoorwaarden in:
1) er wordt gewerkt in iteraties, dus je plant bewust wat je gaat opleveren en stopt niet met ontwikkelen van het product na het opleveren
2) je hebt standaarden afgesproken en hebt een referentie om te bepalen of het afwijkt. Denk hierbij aan architectuur, design standaarden en beheer eisen
3) er wordt bewust omgegaan met businessdoelstellingen en de business wordt op zijn minst geraadpleegd. Als ontwikkel team verplaats je je in wat de gebruiker nodig heeft en maak je niet zelf de keuze. Al helemaal niet om een deadline (hoe oneens je het er ook mee bent) te negeren.

Op deze manier hebt je als ontwikkelaar en als business gezamelijk tools in handen om vaker bruikbare (deel)producten te krijgen en meer feedback te verzamelen. Daar is de introductie van technical debt essentieel in (niet dat het te pas en te onpas gebruikt kan worden als excuus!)

[Q]

Op deze manier hebt je als ontwikkelaar en als business gezamelijk tools in handen om vaker bruikbare (deel)producten te krijgen en meer feedback te verzamelen. Daar is de introductie van technical debt essentieel in (niet dat het te pas en te onpas gebruikt kan worden als excuus!)

Wat je hier in mijn ogen doet is prototyping om de markt te verkennen hernoemen naar technical debt.

De introductie van technical debt maakt het voor een ontwikkel team mogelijk om een iteratie op te leveren waarbij het resultaat niet voldoet aan de afgesproken standaarden maar we hoeven het niet 'slechte code' te noemen.

Ik zal wel naïef zijn maar voor mij zou afwijken van een architectuur of onderhoudbaarheid nooit ever een bargaining chip zijn. Wat wel ter discussie kan staan is welke features wel en niet worden opgeleverd. Maar de features zelf zijn gewoon 'goede' code.

[Sandor_Clegane]

Kan ik me ook wel in vinden.

Dit doet me een beetje denken aan de twee "denkwijzes" voor het uitwerken van een ontwerp/oplossen van een probleem.

Je hebt de denkwijze: we gaan eerst alles op papier zetten en dan maken we het. In de veronderstelling dat we van tevoren alle valkuilen kunnen benoemen en we daardoor direct een goede architectuur neerzetten.

En je hebt de denkwijze: Hoe meer je aan een oplossing of een probleem werkt hoe helderder de probleemstelling wordt, omdat door er mee bezig te zijn duidelijk wordt wat wel werkt en wat niet werkt. Dit iteratieve proces maakt het dat je natuurlijk dingen opnieuw moet doen, voortschrijdend inzicht enzo.

Het grootste probleem is denk ik verantwoording durven nemen en een organisatie neerzetten waarin dit tot uiting komt.

Het probleem hiermee is dat je weer terecht komt in de wereld van YAGNI ( You aint Gonna Need It ) oftewel we abstraheren alles "to the wazoo" en maken alles dynamisch met als gevolg dat alles zo complex is/wordt dat het niet meer te begrijpen is.

Kortom, er is geen silver bullet, denk je dat wel dan leidt dat weer tot cargo culting.

[Q]

Ja, ik ga mee in jouw denkwijze. Ik ben het hier mee eens. En plannen vs. ontdekken: ook dat is gewoon soms lastig maar het ligt helemaal aan de context wat meer voor de hand ligt.

Het grootste probleem is denk ik verantwoording durven nemen en een organisatie neerzetten waarin dit tot uiting komt.

Dat is denk ik de essentie inderdaad. En dat geldt zowel voor de ontwikkelaars als de business.

En cargo culting is echt de ziekte van de hele ICT sector wat mij betreft. Kritisch nadenken lijkt soms erg moeilijk: als in: past dit bij wat wij nodig hebben?

En vraag maar aan drie mensen wat er nodig is en je krijgt drie verschillende antwoorden...

[Sandor_Clegane]

Komt mede omdat de ICT sector erg gestuurd wordt door marketing. Het hele idee dat technologie neutraal is, is een farce, er zitten grote belangen achter om het te maken tot wat het is.

Je ziet het met thought leaders, magic quadrants etc. etc.

Mooi man.

[Ayporos]

"Dat maakt een design niet slecht, maar slechts niet geschikt voor nieuwe requirements die je toen nog niet kende en niet kon voorzien. "

Hier zit hem de crux in denk ik.

Ik heb first hand ervaring met het bouwen van tooling waar in eerste instantie het slechts iets simpels deed.. en toen kwam er een functie bij... en nog een.. en nog een.. en uiteindelijk veranderde het van een specialistisch tooltje naar een 'alles omvattend zwitsers zakmes' en moest er ineens users gelogd worden, logboeken bijgehouden worden, permissies voor bepaalde functies/tools in de 'tool' zelf geregeld worden..

Je gaat geen user&permissie&logging systeem bouwen voor een tooltje dat een simpele query runt tegen je productie database om dat in een excel rapport te exporteren.. maar als je vervolgens 2 jaar later 50 van zulke rapport generatoren hebt én monitoren en allerlei andere dingen die door meerdere afdelingen gebruikt worden ja ga het dan maar eens even overal inbouwen..

Ik denk dus echt dat het ook/voornamelijk een gevolg kan zijn van functionality creep.. ik bedoel kijk naar Windows en de huidige 'audio settings' rompeslomp.
Het oude menu bestaat nog steeds en je kunt er nog steeds komen (en het is nog steeds nodig/handig) maar je moet nu eerst door 3 'new style' menu's heen klikken en zoeken en ze geven allemaal voor ~80% precies dezelfde info/opties weer...

Uiteraard moet je ook niet vergeten dat IT spendering écht een gevoelig/lastig issue is voor een bedrijf dat niet een 'software ontwikkel' bedrijf is.
Ik merk bij mij op het werk dat er écht moeilijk gedaan wordt met IT uitgaven en dat de to-do stapel eindeloos is en dat er altijd weer nieuwe 'dit moet nú met hoogste prioriteit gedaan worden' items bijgegooid worden.

Ga jij als data analist maar eens aan je baas (die géén IT manager is maar gewoon een reguliere manager) vertellen dat je nu een maandje lang niks 'productiefs' gaat opleveren omdat je alle 'technical debt' uit de gehele tooling wilt scheppen. Hij zal je uitlachen...

[Q]

Tja, ik ben het eens met je verhaal. Wat jij beschrijft heeft al een naam: feature creep. Heeft niets met TD te maken

[Ayporos]

Nee?
Want wat 'achteraf', vanuit het perspectief van een 'zwitsers zakmes' beschouwd kan worden als 'slechte code' en onoverzichtelijke modules (i.e. TD?) was op het moment van het schrijven van die modules gewoon prima...

Dat was mijn punt, dat 'slechte code' in de zin van een onoverzichtelijk oerwoud, niet per se opzettelijk noch verwijtbaar is.

Ik zie dat beetje als van die hoarders weet je wel, je koopt iets: het is 1 ding, je bent geen hoarder.
Je koopt een 2e ding, je bent geen hoarder..
Je koopt je 100e ding. Je was geen hoarder toen je je 99e ding kocht.. dus wat maakt 1 extra dingetje nou uit?...
Snap je wat ik bedoel?

[CH4OS]

Technical debt impliceert dat er ooit een bewuste keuze is gemaakt om nu snel een feature op te leveren met brakke code om op een later moment die lening terug te betalen, dus om die brakke code door goede code te vervangen.

Een vaak voorbij komende quote is 'Niets is zo permanent als tijdelijke code' in de software wereld. Dus ja, alleen hier al om is technical debt zeker wel een ding, vooral als gehaast features/updates uitgebracht (moeten) worden, waardoor de kans op bugs ook nog eens groter is.

Hoe vaak gebeurt dit werkelijk in de praktijk?
Hoe vaak wordt deze keuze heel bewust genomen in samenspraak met de business?

De afgelopen paar jaar dat ik bij werkgevers heb gezien, best veel. Ook wordt vaak gewoon door gebouwd op oude software en frameworks die niet eens meer onderhouden worden en dus geen updates meer krijgen. En, niet te vergeten (zoals in de tekst ook al genoemd); een best-practice van 4 jaar geleden, kan best achterhaald zijn en daardoor dus alsnog een technical debt / blok aan het been worden. Dan is het niet per definitie slecht, maar is het - 4 jaar later - wel een keer tijd om die specifieke code eens nader te bekijken en eventueel te refactoren.

Mijn indruk is dat Technical Debt te pas en te on pas - mede op basis van wat ik van andere mensen hoor - wordt gebruikt om verantwoordelijkheid voor code te ontlopen. We geven niet toe dat we 'destijds' gewoon slechte code hebben opgeleverd, we noemen het 'technical debt'.

Ook hier kan ik wel vraagtekens bij zetten. Die gemaakte keuzes uit het verleden, hoeven niet per se door medewerkers of zelfs door het bedrijf gemaakt te zijn. Waar ik nu werk hebben we een project, dat intussen best een technical debt heeft, maar waar de keuzes soms zelfs komen uit een tijd dat het project nog niet in ons beheer was. Daarnaast gaat het ook helemaal niet om 'afschuiven van verantwoordelijkheid', maar is het een kwestie van aangeven waar de pijn zit, wat niet alleen enorm vertragend werkt, maar ook nog eens foutgevoelig is, zeker naar mate de complexiteit toeneemt.

Moeilijke vragen zoals: hoe kan het dat we met elkaar slechte code opleveren? Wat gaat er mis in ons design proces? Wat gaat er mis in ons ontwikkelproces? Hoe zouden we dat kunnen verbeteren?

Omdat deze vragen 9zie hierboven) dus best genuanceerder kunnen liggen. Het hoeft dus niet aan het eigen proces te liggen, zoals gezegd kan dus het ontwerp van (een deel van) de applicatie volledig van buitenaf zijn gekomen, omdat het project later in beheer is genomen, of de bedenker / schrijver van de code intussen met de horizon is vertrokken en het project alleen deed.

Ik vind dit helemaal geen technical debt. Het is puur dat de wereld veranderd en of je kunt er makkelijk in mee, of niet omdat het design dit niet makkelijk toestaat.

Toch kun je dit ook onder technical debt scharen. Hoewel het niet van het 'kwalijkste' soort is, kan het wel degelijk voor problemen of vertraging zorgen verderop 'down the line' en dat wil je het liefste voorkomen. Upgraden / migreren / refactoren zou dus eigenlijk zo snel mogelijk gedaan moeten worden wanneer blijkt dat het achterhaald is, maar helaas is dat een utopie. Bij het project waar ik eerder over sprak is het zelfs zo dat de focus (dit jaar) ligt op wat meer visueel functies toevoegen, zodat de klant van de klant daadwerkelijke veranderingen ziet, waardoor dus dit soort werk blijft liggen, want het heeft geen of minder prioriteit. Zo nu en dan komt er dan wel een bug voorbij dat opeens opgelost moet worden, maar is dan vooral omdat men in de praktijk er tegenaan loopt, terwijl het dus (in sommige gevallen) best voorkomen had kunnen worden.

Dat maakt een design niet slecht, maar slechts niet geschikt voor nieuwe requirements die je toen nog niet kende en niet kon voorzien.

Soms ontstaan er ook betere of veiligere methoden om zaken te regelen, dat maakt niet bijvoorbeeld het oude package dat gebruikt werd 'opeens' uit den boze is.

Maar waarom zouden we dan een andere term gebruiken? Waarom zouden we gewoon niet kunnen zeggen dat het design niet geschikt is om de nieuwe requirements te faciliteren? En dat je daar dan gewoon iets mee gaat doen?

Het liefste wil je dat een website of applicatie zo modulair mogelijk is opgebouwd, dat zaken (en externe packages dus ook) simpelweg vervangbaar zijn. Dat maakt het beheer van de code veel gemakkelijker, zonder vast te hoeven blijven zitten en kun je altijd met de tijd mee. Doordat projecten vast blijven in oude code, wordt het mettertijd ook steeds lastiger om fatsoenlijk geautomatiseerde tests te kunnen doen, omdat je constant rekening moet houden met (ver)oude(rde) methodieken.

[Reactie gewijzigd door CH4OS op 22 juli 2024 21:26]

[Q]

Een vaak voorbij komende quote is 'Niets is zo permanent als tijdelijke code' in de software wereld. Dus ja, alleen hier al om is technical debt zeker wel een ding, vooral als gehaast features/updates uitgebracht (moeten) worden, waardoor de kans op bugs ook nog eens groter is.

Ik denk dat dit eigenlijk meer een cultureel probleem is en een communicatie probleem. Ik denk dat we er niets mee opschieten om dit te bestempelen als technical debt.

Ik vraag me sterk af wat er aan de hand is dat er een situatie ontstaat dat 'gehaast features/updates' uitgebracht moeten worden. Bij updates denk ik aan bugfixes maar dat is gewoon een kwestie van fouten repareren, dat TD noemen is alleen maar obfuscatie wat mij betreft.

En dat is mijn grote probleem met de term: ik vermoedt dat TD inderdaad in verruit de meeste gevallen als een obfuscatie tactiek wordt ingezet om te verdoezelen wat er werkelijk aan de hand is.

Ook hier kan ik wel vraagtekens bij zetten. Die gemaakte keuzes uit het verleden, hoeven niet per se door medewerkers of zelfs door het bedrijf gemaakt te zijn.

De code is goed of slecht en het maakt conceptueel niet uit waar de keuze vandaan komt.

Waar ik nu werk hebben we een project, dat intussen best een technical debt heeft, maar waar de keuzes soms zelfs komen uit een tijd dat het project nog niet in ons beheer was.

Dat maakt voor de inhoudelijke kwaliteit van de code niets uit, dat is gewoon code met een bepaald kwaliteitsniveau en met een bepaalde fit op de huidige business problems, niets meer en niets minder. En daar moet je dan wat mee, of niet.

Dit noem ik geen technical debt.

Daarnaast gaat het ook helemaal niet om 'afschuiven van verantwoordelijkheid', maar is het een kwestie van aangeven waar de pijn zit, wat niet alleen enorm vertragend werkt, maar ook nog eens foutgevoelig is, zeker naar mate de complexiteit toeneemt.

Als er pijn in de code zit vanwege lage kwaliteit of slechte architectuurkeuzes, dan is dat niet meer dan precies dat. Dat is geen technical debt. De essentie is eerder een kennis/kunde probleem was in het verleden en dat het bedrijf dat niet goed kon sturen, of dat iets is waar je nog wat mee kunt, is dan een andere vraag.

Op geen enkel moment - in dit scenario zoals je het nu beschrijft - nam iemand bewust bepaalde keuzes waarbij ze later van plan waren om de boel recht te trekken. In tegen deel, het lijkt er op alsof ze niet beter wisten.

En dan spreek ik even - grof gezegd - van onkunde en gebrek aan expertise en niet van de voor mij lege term 'TD'.
Het is voor een bedrijf dan ook veel interessanter om na te gaan hoe deze situatie heeft kunnen ontstaan en het niet af te doen als TD.

Omdat deze vragen 9zie hierboven) dus best genuanceerder kunnen liggen. Het hoeft dus niet aan het eigen proces te liggen, zoals gezegd kan dus het ontwerp van (een deel van) de applicatie volledig van buitenaf zijn gekomen, omdat het project later in beheer is genomen, of de bedenker / schrijver van de code intussen met de horizon is vertrokken en het project alleen deed.

Dat een bedenker of schrijver weg is maakt niets uit. Dat de code alleen werd gedaan maakt niets uit. Dat het aan andermans proces ligt maakt niets uit. De schuld vraag maakt niets uit. Als er onvoldoende documentatie is over de processen en begrip van de code, dan is dus dat het probleem. Dat onder de noemer TD scharen is betekenisloos. Het biedt geen nieuw inzicht.

Het levert zeker wel problemen op maar laten we het beestje bij de expliciete naam noemen.

In deze situatie heb je niet met TD te maken, maar gewoon met slecht (gecoducmenteerde/geteste/bla) code. En dan is het gewoon een kwestie van keuzes hoe je er mee om gaat, en wat de omstandigheden toestaan.

(over veranderende requirements) Toch kun je dit ook onder technical debt scharen. Hoewel het niet van het 'kwalijkste' soort is, kan het wel degelijk voor problemen of vertraging zorgen verderop 'down the line' en dat wil je het liefste voorkomen.

Nee, dat vind ik helemaal onterecht. Noem het beestje bij de naam, de omstandigheden zijn veranderd. Passen de gekozen architecturele keuzes niet zo goed meer bij deze omstandigheden, tja dat is dan dat en niets meer. Je kunt dat geen technical debt noemen want je maakte 'destijds' nooit bewust de keuze op deze manier, dit is allemaal 'gelul' achteraf.

Je kunt gerust een discussie voeren in hoeverre de architectuur flexibel genoeg was om met toekomstige veranderingen om te kunnen gaan, maar er is een grens aan hoe flexibel je kunt zijn zonder té flexibel te worden en teveel overhead vereisen in de code (of het veel te complex te maken). Het is dus altijd een afweging / design keuze. De ene keuze is misschien beter dan de andere. Maar dat is het dan. Meer niet. Doen alsof dit een vorm van Technical debt is, verdoezeld alleen maar wat er werkelijk aan de hand is.

Soms ontstaan er ook betere of veiligere methoden om zaken te regelen, dat maakt niet bijvoorbeeld het oude package dat gebruikt werd 'opeens' uit den boze is.

Dan kun je zeggen dat we met nieuwe kennis zaken nu 'beter' of 'anders' hadden aangepakt, maar dat is altijd zo. Dat is een inherent gegeven van ieder ontwikkel proces, waarbij je continue nieuwe inzichten verwerft, nieuw begrip vormt. In dat proces TD introduceren is dan niets anders dan alles wat je gister deed afdoen als technical debt, maar daar kun je niets mee, het is dan verworden tot een betekenisloze term, voor zover de term werkelijk betekenis had.

Het liefste wil je dat een website of applicatie zo modulair mogelijk is opgebouwd, dat zaken (en externe packages dus ook) simpelweg vervangbaar zijn. Dat maakt het beheer van de code veel gemakkelijker, zonder vast te hoeven blijven zitten en kun je altijd met de tijd mee. Doordat projecten vast blijven in oude code, wordt het mettertijd ook steeds lastiger om fatsoenlijk geautomatiseerde tests te kunnen doen, omdat je constant rekening moet houden met (ver)oude(rde) methodieken.

Het blijft altijd een trade-off want de vraag is altijd waar je die grenzen trekt. Je kunt niet iedere regel code modulair maken, je moet een architectuur neerzetten en dat blijft altijd een compromis. Alles maar modulair maken is echt niet de oplossing en het maakt het redeneren over code ook moeilijker.

Het is dus duidelijk geen panacee en uiteindelijk is alles een compromis en een compromis houdt in dat sommige aspecten niet optimaal zullen zijn. En we accepteren dan dat het niet optimaal is en daarmee is dan de kous af, op geen enkel moment hebben we het dan over TD of komt dat überhaupt in de picture.

[CH4OS]

Ik denk dat dit eigenlijk meer een cultureel probleem is en een communicatie probleem. Ik denk dat we er niets mee opschieten om dit te bestempelen als technical debt.

Ik vraag me sterk af wat er aan de hand is dat er een situatie ontstaat dat 'gehaast features/updates' uitgebracht moeten worden. Bij updates denk ik aan bugfixes maar dat is gewoon een kwestie van fouten repareren, dat TD noemen is alleen maar obfuscatie wat mij betreft.

Nee, dit is geen communicatieprobleem, verre van zelfs. Soms worden zaken 'even snel' opgelost (want haast bijvoorbeeld bij een hotfix). Dan komt er een comment met een @todo erbij, maar dat staat dan enkele jaren later nog. Met andere woorden; op voorhand is bekend dat het gewoon niet goed is, maar doordat tijd een probleem is, kan het niet (op dat moment) op de mooie en nette manier opgelost worden.

Dat is dus wel degelijk technical debt. Met technical debt is het geenszins de bedoeling om eea te verdoezelen, als je denkt dat dat het doel is van technical debt, dan zit je er echt helemaal naast. Met de technical debt worden obscure stukken code bedoeld, die bijvoorbeeld onduidelijk of slecht gedocumenteerd zijn, of complex opgebouwd, om wat voorbeelden te geven. Het is geen dingetje om zaken als 'technical debt' weg te moffelen, het is code waar de programmeurs vroeg of laat tegenaan lopen omdat het bijvoorbeeld te complex is, te verouderd of geen best practice meer is.

Zo hebben wij onlangs een aanpassing gedaan in de database van een applicatie ivm enorm nijpende performance issues, waar wij op voorhand al zeiden dat er gekeken moet worden naar de applicatie (op alle vlakken), maar mijn voorgevoel zegt mij dat het uiteindelijke probleem (zonder in al teveel details op te treden) dat nu door de fix geïntroduceerd is, niet opgelost gaat worden, of dat dat heel lang gaat duren en wij uiteindelijk weer opgetrommeld worden om het op te gaan lossen.

De code is goed of slecht en het maakt conceptueel niet uit waar de keuze vandaan komt.

Jazeker maakt dat wel uit. Er zijn vele wegen die naar Rome leiden, en zo zijn er net zoveel wegen die een oplossing kunnen zijn voor (programmeer)vraagstukken. De een is kwalitatief gezien beter dan de ander, maar dat betekend niet dat altijd de beste keuze gemaakt wordt, dat overigens door verschillende zaken gemaakt kan worden.

Als er pijn in de code zit vanwege lage kwaliteit of slechte architectuurkeuzes, dan is dat niet meer dan precies dat. Dat is geen technical debt. De essentie is eerder een kennis/kunde probleem was in het verleden en dat het bedrijf dat niet goed kon sturen, of dat iets is waar je nog wat mee kunt, is dan een andere vraag.

De technical debt zit in zulke situaties in het wegwerken van de slechte (kwaliteit van de) code. Je moet de architectuur los zien van de code, dat zijn twee heel aparte zaken!

Nee, dat vind ik helemaal onterecht. Noem het beestje bij de naam, de omstandigheden zijn veranderd. Passen de gekozen architecturele keuzes niet zo goed meer bij deze omstandigheden, tja dat is dan dat en niets meer. Je kunt dat geen technical debt noemen want je maakte 'destijds' nooit bewust de keuze op deze manier, dit is allemaal 'gelul' achteraf.

De omstandigheden zijn verbeterd, er is betere techniek beschikbaar, zolang je op het oude blijft zul je dat vroeg of laat een keer willen omzetten naar het nieuwe, zodat de applicatie flexibel en beheersbaar blijft. Dat is wat nieuwe best practices tot gevolg hebben als technical debt. Zoals gezegd, dat is niet erg, er zijn dus zeker meerdere vormen van technical debt te onderscheiden.

De architectuur van een (web)applicatie staat eigenlijk los van de code zelf. Het is niet aan de architectuur om te bepalen hoe de code eruit komt te zien, zolang de code maar doet wat er vanuit de architectuur ontworpen is dat het zou moeten doen. Op architectuur zeg je: Ik stop hier 10 in, dan gebeurd er een proces en komt er uiteindelijk 1000 uit, hoe de code dat onderhuids oplost, moet voor de architectuur niets uitmaken, het resultaat is waar het om gaat in de architectuur.

Dan kun je zeggen dat we met nieuwe kennis zaken nu 'beter' of 'anders' hadden aangepakt, maar dat is altijd zo. Dat is een inherent gegeven van ieder ontwikkel proces, waarbij je continue nieuwe inzichten verwerft, nieuw begrip vormt. In dat proces TD introduceren is dan niets anders dan alles wat je gister deed afdoen als technical debt, maar daar kun je niets mee, het is dan verworden tot een betekenisloze term, voor zover de term werkelijk betekenis had.

Achteraf is mooi wonen, is wat je hier omschrijft. En tot op zekere hoogte is dat ook zeker waar, maar doordat de techniek evolueert en een applicatie mee kan, is datgene wat de applicatie tegenhoudt om die beweging te kunnen maken wel degelijk technical debt, hoe groot of klein ook. Als er geen wil is om te verbeteren, dan is het inderdaad ook geen technical debt, want dan werkt het zoals bedoeld, immers.

Het blijft altijd een trade-off want de vraag is altijd waar je die grenzen trekt. Je kunt niet iedere regel code modulair maken, je moet een architectuur neerzetten en dat blijft altijd een compromis. Alles maar modulair maken is echt niet de oplossing en het maakt het redeneren over code ook moeilijker.

Je hoeft dat ook zeker niet per regel te doen, uiteindelijk gaat het erom dat wat er in gestopt wordt, volgens de architectuur verwerkt wordt naar iets anders, of dat het geregistreerd wordt, bijvoorbeeld. De architectuur mag mijns inziens in elk geval nooit bepalen hoe de code eruit ziet, die bepaalt enkel wat iets functioneel gezien moet doen.

[Reactie gewijzigd door CH4OS op 22 juli 2024 21:26]

[Q]

Nee, dit is geen communicatieprobleem, verre van zelfs. Soms worden zaken 'even snel' opgelost (want haast bijvoorbeeld bij een hotfix). Dan komt er een comment met een @todo erbij, maar dat staat dan enkele jaren later nog. Met andere woorden; op voorhand is bekend dat het gewoon niet goed is, maar doordat tijd een probleem is, kan het niet (op dat moment) op de mooie en nette manier opgelost worden.

Dit is vaak meer een persoonlijke keuze van mensen die gewoon de tijd niet even pakken om op een rustiger moment de 'todo' even af te handelen dan dat dit iets te maken heeft met TD. En ik ben helemaal argwanend ten opzichte van argumenten over tijd, die druk is zelfden zo hoog en vaak zelden gerechtvaardigd.

Met de technical debt worden obscure stukken code bedoeld, die bijvoorbeeld onduidelijk of slecht gedocumenteerd zijn, of complex opgebouwd, om wat voorbeelden te geven.

Dan hou jij er een hele andere definitie op na van wat technical debt volgens de meeste mensen is: nu een shortcut nemen voor business value om die later te fixen. Dus nu een lening nemen om die later (met rente) terug te betalen (en netto onder de streep winst te hebben behaald).

Dat heeft niets met obscure code te maken die slecht gedocumenteerd is. Die code is precies en alleen dat: slechte code met slechte documentatie.

Dat is zeker een belemmering bij het ontwikkelen van nieuwe functionaliteit, maar niet iedere belemmering is meteen ontstaan door 'technical debt'.

En bovendien: als we weten dat het slechte code is of dat er onvoldoende context is gedocumenteerd waardoor we veel tijd kwijt zijn met reverse engineren van zowel code als het proces dat de code implementeert, hebben we daarmee niet meteen het hele probleem beschreven?

Het technical debt noemen (wat in in deze situatie niet eens gerechtvaardigd lijkt) voegt niet eens wat toe aan de begripsvorming.

Dat slechte keuzes uit het verleden nu problemen veroorzaken is geen technical debt.

Het is geen dingetje om zaken als 'technical debt' weg te moffelen, het is code waar de programmeurs vroeg of laat tegenaan lopen omdat het bijvoorbeeld te complex is, te verouderd of geen best practice meer is.

Nee, dat is gewoon verouderde code en niets meer dan dat. Nergens wordt bewust een lening genomen op de toekomst, in samenspraak met de business, compleet met een concreet moment waarom we die lening gaan 'terug betalen'.

Zo hebben wij onlangs een aanpassing gedaan in de database van een applicatie ivm enorm nijpende performance issues, waar wij op voorhand al zeiden dat er gekeken moet worden naar de applicatie (op alle vlakken), maar mijn voorgevoel zegt mij dat het uiteindelijke probleem (zonder in al teveel details op te treden) dat nu door de fix geïntroduceerd is, niet opgelost gaat worden, of dat dat heel lang gaat duren en wij uiteindelijk weer opgetrommeld worden om het op te gaan lossen.

Dit s niet anders dan een business keuze. De quick-fix die je hebt toegepast zal misschien even ademruimte geven (of misschien wel langer) maar blijkbaar willen ze nu die kosten niet maken. En wie weet komen ze er nog lang mee weg.

Heeft niets te maken met technical debt. Er is duidelijk een probleem en dat kun je met een korte-termijn fix oplossen of structureel. Beiden vereisen ieder een prijs. Maar dat is gewoon een business afweging.

De technical debt zit in zulke situaties in het wegwerken van de slechte (kwaliteit van de) code. Je moet de architectuur los zien van de code, dat zijn twee heel aparte zaken!

We hebben duidelijk een verschillende definitie van technical debt. En slechte code is niet meer dan dat. Het wegwerken van slechte code is niet meer dan dat. Het heeft niets te maken met dat concept van bewust een lening aan gaan om die later terug te betalen met hopelijk business value als resultaat.

Wat ik hier lees is dat mogelijk niet zo competente mensen (en dat is meestal niet 1 persoon) gewoon slechte code hebben opgeleverd. Meer niet.

De omstandigheden zijn verbeterd, er is betere techniek beschikbaar, zolang je op het oude blijft zul je dat vroeg of laat een keer willen omzetten naar het nieuwe, zodat de applicatie flexibel en beheersbaar blijft. Dat is wat nieuwe best practices tot gevolg hebben als technical debt. Zoals gezegd, dat is niet erg, er zijn dus zeker meerdere vormen van technical debt te onderscheiden.

Er zijn geen 'vormen van technical debt', wat moet ik me daarbij voorstellen?

Het enige wat je hier schetst is puur een deel onderhoud en een deel voortschrijdend inzicht. Dat je leert hoe iets beter/efficiënter kan maakt de oude code nog geen 'technical debt'.

En dat je misschien eens een PHP versie of Python versie moet upgraden, dat is puur maintenance. Dat nalaten is puur achterstallig onderhoud, geen 'technical debt'.

Oude code die destijds prima werkte voor een 'betere' of efficiëntere oplossing is puur een verbetering, meer niet.

De architectuur van een (web)applicatie staat eigenlijk los van de code zelf. Het is niet aan de architectuur om te bepalen hoe de code eruit komt te zien, zolang de code maar doet wat er vanuit de architectuur ontworpen is dat het zou moeten doen. Op architectuur zeg je: Ik stop hier 10 in, dan gebeurd er een proces en komt er uiteindelijk 1000 uit, hoe de code dat onderhuids oplost, moet voor de architectuur niets uitmaken, het resultaat is waar het om gaat in de architectuur.

Nee, je verwart hier architectuur met proces. De business logic vertelt jou dat als je hier 10 instopt dat je er dan 1000 uit moet krijgen.

Architectuur vind je terug in het framework wat je gebruikt (en/of zelf schrijft) om die processen te modelleren. De architectuur zit 'm in de abstracties en modellen in je code.

Lijkt mij dan.

Achteraf is mooi wonen, is wat je hier omschrijft. En tot op zekere hoogte is dat ook zeker waar, maar doordat de techniek evolueert en een applicatie mee kan, is datgene wat de applicatie tegenhoudt om die beweging te kunnen maken wel degelijk technical debt, hoe groot of klein ook. Als er geen wil is om te verbeteren, dan is het inderdaad ook geen technical debt, want dan werkt het zoals bedoeld, immers.

Oh dat laatste is zeker. Maar ik ga gewoon niet mee in de gedachte dat legitieme keuzes uit het verleden onder nieuwe omstandigheden of met nieuwe kennis plots als 'technical debt' worden bestempeld. Maar wederom is dat hier een definitie kwestie.

Het voegt ook niets toe om zo'n bottleneck als technical debt te bestempelen, het leert je niets. Het scenario wat je hier schetst staat helemaal op zichzelf, het is gewoon heel duidelijk wat er aan de hand is. En de keuze is dan om toch voort te borduren op wat er is voor korte-termijn resultaat, of de tijd pakken voor structurele verbeteringen voor de langere termijn en wat hier de goede keuze is staat niet bij voorbaat vast, dat is extreem context afhankelijk.

[Reactie gewijzigd door Q op 22 juli 2024 21:26]

[CH4OS]

Dan hou jij er een hele andere definitie op na van wat technical debt volgens de meeste mensen is: nu een shortcut nemen voor business value om die later te fixen. Dus nu een lening nemen om die later (met rente) terug te betalen (en netto onder de streep winst te hebben behaald).

Technical debt is niet alleen omdat er gekozen is voor een shortcut, dat staat ook duidelijk in de tekst. Het is een van de voorbeelden.

Oh dat laatste is zeker. Maar ik ga gewoon niet mee in de gedachte dat legitieme keuzes uit het verleden onder nieuwe omstandigheden of met nieuwe kennis plots als 'technical debt' worden bestempeld. Maar wederom is dat hier een definitie kwestie.

De keuze zelf die destijds gemaakt is, is inderdaad geen technical debt, de tijd en code die nodig is om over te schakelen naar de nieuwe best practice (omdat die veiliger, sneller of welke superlatief dan ook) is dat wel. Hoe langer je op de oude best practice blijft zitten, hoe hoger de kosten worden om ervan te migreren.

En dat je misschien eens een PHP versie of Python versie moet upgraden, dat is puur maintenance. Dat nalaten is puur achterstallig onderhoud, geen 'technical debt'.

Totdat je PHP niet kan upgraden (met alle risico's van dien) omdat de impact op de webapplicatie te groot is. Een mooi voorbeeld is Zend Framework 1. Een PHP-framework, wat werkt t/m PHP 7.1, maar intussen is PHP 7.4 er al. Je wilt PHP graag upgraden, maar kan dus niet, omdat Zend Framework 1 gewoon niet compatible is met PHP 7.4. Dan is de applicatie zo goed als in zijn geheel technical debt; het is blocking om verder te kunnen en Zend Framework 1 aanpassen zodat het wel op PHP 7.4 werkt is, zonder support van de originele ontwikkelaar, onbegonnen werk.

[Reactie gewijzigd door CH4OS op 22 juli 2024 21:26]

[Q]

Technical debt is niet alleen omdat er gekozen is voor een shortcut, dat staat ook duidelijk in de tekst. Het is een van de voorbeelden.

Je hebt gelijk als we kijken naar deze definities. Dus ik geef toe dat ik de definitie te 'eng' lees.

Veel van die definities zijn erg tegenstrijdig. Want een lening neem je bewust (niet in je slaap) en veel van de voorbeelden die worden gegeven komen tot stand door 'onbewuste onkunde'. En je neemt geen onbewuste leningen. Dat vind ik onzin.

Maar in die zin ben ik het dus fundamenteel oneens om het concept te hanteren. Het maskeert het werkelijke probleem. En dat is die lijst in de 'causes' section.

Heel veel van die 'lack of ....' items lezen in mijn ogen als: het werk is gewoon nooit afgemaakt.

Eigenlijk kom ik hier weer terug bij af: bij mijn oorspronkelijke post. En wat je ziet - conform de wikipedia defintie - dat heel veel disfunctioneel maar verschillend gedrag onder de noemer wordt geveegd zodat eigenlijk alles wat productiviteit hindert als technical debt kan worden aangemerkt en daarmee verwatert het tot een betekenisloos concept.

De keuze zelf die destijds gemaakt is, is inderdaad geen technical debt, de tijd en code die nodig is om over te schakelen naar de nieuwe best practice (omdat die veiliger, sneller of welke superlatief dan ook) is dat wel. Hoe langer je op de oude best practice blijft zitten, hoe hoger de kosten worden om ervan te migreren.

Daar over verschillen we dan maar van mening

Totdat je PHP niet kan upgraden (met alle risico's van dien) omdat de impact op de webapplicatie te groot is. Een mooi voorbeeld is Zend Framework 1. Een PHP-framework, wat werkt t/m PHP 7.1, maar intussen is PHP 7.4 er al. Je wilt PHP graag upgraden, maar kan dus niet, omdat Zend Framework 1 gewoon niet compatible is met PHP 7.4. Dan is de applicatie zo goed als in zijn geheel technical debt; het is blocking om verder te kunnen en Zend Framework 1 aanpassen zodat het wel op PHP 7.4 werkt is, zonder support van de originele ontwikkelaar, onbegonnen werk.

Dit is puur een verhaal van achterstallig onderhoud en dat ga ik niet hernoemen naar 'technical debt'. Dit is gewoon voor mij achterstallig onderhoud en niets meer. Ik denk niet dat deze situatie tot stand is gekomen door heel bewuste keuzes van ontwikkelaars in samenspraak met de business.

En als je in die context eigenlijk niet zonder de originele ontwikkelaar kunt, dan is er misschien nog wel meer aan de hand en dat heeft wat mij betreft helemaal niets meer met technical debt te maken.

Dan komen we op het vlak van management, business continuity, enzovoort terecht.

[Reactie gewijzigd door Q op 22 juli 2024 21:26]

[CH4OS]

Dit is puur een verhaal van achterstallig onderhoud en dat ga ik niet hernoemen naar 'technical debt'. Dit is gewoon voor mij achterstallig onderhoud en niets meer. Ik denk niet dat deze situatie tot stand is gekomen door heel bewuste keuzes van ontwikkelaars in samenspraak met de business.

Nee, dit heeft niets met achterstallig onderhoud te maken. In dit geval is het een bewuste keuze geweest van ofwel de klant ofwel het bedrijf waar je werkt, om niet te investeren in goede doorontwikkeling en onderhoudbaarheid van de code. De situatie die ik net hierboven vertelde, is letterlijk gebeurd, waar we met z'n tweetjes de development- / IT-afdeling waren en de ruimte voor dergelijke refactoring, ondanks dat wij het beiden zagen en aangekaart hadden, er gewoon niet was.

En als je in die context eigenlijk niet zonder de originele ontwikkelaar kunt, dan is er misschien nog wel meer aan de hand en dat heeft wat mij betreft helemaal niets meer met technical debt te maken.

De originele ontwikkelaar is dan de originele ontwikkelaar van Zend Framework 1. Uiteindelijk zit je met een applicatie dat gebaseerd is op een bonk oude code. Dat is (voor de applicatie) juist technical debt. De rest eromheen is totaal niet interessant (als ontwikkelaar zijnde).

Dan komen we op het vlak van management, business continuity, enzovoort terecht.

Dat komt dan ook in het geding, maar hey, zolang de applicatie draait, zul je hen niet horen 'want de applicatie draait toch nog?'.

Ik krijg ondanks de indruk dat je nog altijd denkt dat technical debt iets is wat onder de tafel geschoven moet worden, of het geen technical debt moet zijn. Maar zie het als een monteur in een garage. De old timers zijn daarbij niet aan de laptop aan te sluiten om de motor uit te lezen om te kijken wat er is, terwijl moderne auto's, busjes en vrachtwagens dat wel hebben. Aan welke auto zou een moderne monteur wel willen sleutelen denk je?

[Reactie gewijzigd door CH4OS op 22 juli 2024 21:26]

[Q]

Nee, dit heeft niets met achterstallig onderhoud te maken. In dit geval is het een bewuste keuze geweest van ofwel de klant ofwel het bedrijf waar je werkt, om niet te investeren in goede doorontwikkeling en onderhoudbaarheid van de code. De situatie die ik net hierboven vertelde, is letterlijk gebeurd, waar we met z'n tweetjes de development- / IT-afdeling waren en de ruimte voor dergelijke refactoring, ondanks dat wij het beiden zagen en aangekaart hadden, er gewoon niet was.

Nou ja, dan kies je bewust om geen onderhoud uit te voeren, ook goed, maakt mij ook verder niet uit eigenlijk, ik ga er in mee: het punt blijft staan.

Dat je taal en framework verder worden doorontwikkeld en dat je de code aanpast om met hogere versies te kunnen blijven werken zie ik puur als onderdeel van life-cycle-management.

Dat is een gegeven. Als je kiest om daar van af te wijken, dan kies je in feite om de olie niet te verversen.

De situatie die ik net hierboven vertelde, is letterlijk gebeurd, waar we met z'n tweetjes de development- / IT-afdeling waren en de ruimte voor dergelijke refactoring, ondanks dat wij het beiden zagen en aangekaart hadden, er gewoon niet was

Zoals je het nu schetst is het niets anders dan er voor kiezen om geen onderhoud te plegen. En dat is niet erg, zeker als het een oude auto betreft, kan ik me voorstellen dat je 'm gewoon oprijdt. En anders dan weet je wat de gevolgen zijn.

De originele ontwikkelaar is dan de originele ontwikkelaar van Zend Framework 1. Uiteindelijk zit je met een applicatie dat gebaseerd is op een bonk oude code. Dat is (voor de applicatie) juist technical debt. De rest eromheen is totaal niet interessant (als ontwikkelaar zijnde).

Dat is grappig: want iets 'technical debt' noemen is niet informatief. Dat zegt effectief niets over wat er aan de hand is. De details en context maken super veel uit, dus noem het beestje gewoon bij de naam: verouderde code. En het hangt helemaal van de context af wat de consequenties zijn van deze verouderde code. Je kunt er voor kiezen om gewoon niet te upgraden en door te gaan met de code.

Ook dat heeft consequenties maar de term Technical Debt verduidelijkt niets. Volgens de wikipedia definities kan ik waarschijnlijk de code die je gister schreef al classificeren als technical debt. En daarmee is de term betekenisloos geworden. En met leningen heeft het al helemaal niets meer te maken.

Dat komt dan ook in het geding, maar hey, zolang de applicatie draait, zul je hen niet horen 'want de applicatie draait toch nog?'.

En strikt genomen hebben ze nog gelijk ook, dus wat is eigenlijk hier de business case om daadwerkelijk te upgraden? Context maakt uit. Als er nog een paar kleine wijzigingen nodig zijn, tja. Is er dan een probleem? Security kan een issue zijn, maar als het intern draait.... Tja.

Ik krijg ondanks de indruk dat je nog altijd denkt dat technical debt iets is wat onder de tafel geschoven moet worden, of het geen technical debt moet zijn. Maar zie het als een monteur in een garage. De old timers zijn daarbij niet aan de laptop aan te sluiten om de motor uit te lezen om te kijken wat er is, terwijl moderne auto's, busjes en vrachtwagens dat wel hebben. Aan welke auto zou een moderne monteur wel willen sleutelen denk je?

De term technical debt is een betekenisloze vergaarbak die niemand iets wijzer maakt. De term is zo breed gedefinieerd dat alles er onder kan vallen en daarmee weet je dus nooit wat het precies concreet in een situatie inhoudt.

Daarom kun je veel beter spreken over het specifieke issue wat tot problemen leidt. Dat is wel informatief en dus actionable.

Om op je analogie in te gaan: oude auto's hebben dan wel geen computer diagnostiek, de techniek is zoveel simpler dat het eigenlijk ook niets op zou leveren. De huidige computer-gestuurde motoren die met complexe firmware zijn uitgerust om aan moderne uitstootseisen te voldoen zouden best wel eens voor lastigere en moeilijker op te lossen problemen kunnen veroorzaken dan die oude auto's.



Het is allemaal niet zo zwart-wit en daarmee geef ik wederom aan hoe nutteloos het is om alles wat ook maar in theorie een bottleneck kan vormen voor het ontwikkelproces af te doen als technical debt. Je wordt er wat mij betreft niets wijzer van.

Ik denk dat we op het punt zijn dat als jij als ontwikkelaar een vrije dag neemt dat dit al tot technical debt leidt

[Reactie gewijzigd door Q op 22 juli 2024 21:26]

[J_van_Ekris]

Maar waarom zouden we dan een andere term gebruiken? Waarom zouden we gewoon niet kunnen zeggen dat het design niet geschikt is om de nieuwe requirements te faciliteren? En dat je daar dan gewoon iets mee gaat doen?

Tja, "achterstallig onderhoud" dekt misschien ook de lading, maar klinkt minder sexy. Net als je huis moeten systemen (en de onderliggende codebase) onderhouden worden, net als een huis regelmatig een likje verf nodig heeft of dat door ander gebruik (geboorte of vertrek kinderen) delen van het huis een andere bestemming krijgen. In software zien we dit ook: platformen veranderen (dus software rot), gebruik veranderd, aannames blijken onhoudbaar. Ook is er regelmatig sprake van roofbouw, waarbij zaken onder hoge druk worden uitgerold en men plechtig belooft de ellende op te ruimen zodra het kan (niet dus).

In Agile kent men de term "refactoring" om het in een project op te lossen, zelf roep ik wel eens "grote schoonmaak" om hetzelfde te doen op architectuurniveau. Je moet soms je ontwikkelteam de ruimte geven om de ellende op te poetsen om weer effectief te worden. Er wordt in een systeem geleefd, rommel ontstaat gewoon.

Het beschreven puntensysteem kan helpen om de ellende te identificeren, maar het heeft het nadeel dat je heel fragmentarisch aan het werk gaat. Zelf geloof ik er meer in een deelsysteem eens goed onderhanden te nemen. Maar dat is voorkeur en omvang waar je mee bezig bent denk ik.

[J_van_Ekris]

Verder mee eens hoor!, maar zeker dat roofbouw stuk: dat is toch geen technical debt meer, dat is toch gewoon 'gestoorde bedrijfsvoering'? Geef dan gewoon toe dat je met de levensvatbaarheid van je bedrijf aan het gokken bent, maar ga er toch geen 'bullshit' termen op plakken.

Een bedrijf runnen is risico's nemen, en software is gewoon een bedrijfsmiddel waar geld mee verdiend wordt. Als je gat wachten tot de architect perfectie bereikt heeft, wordt er geen cent meer verdiend....

Ik geef toe dat ik een beetje een buitenstaander ben maar hoezo 'rommel ontstaat gewoon'? Ik vind dat helemaal niet gewoon. Het hele proces is toch bedoeld, met code reviews, geautomatseerde builds, etc dat er toch geen rommel ontstaat?

Rommel hoeft niet uit je eigen ontwerp te komen. Anderen kunnen het verprutsen, maar als je de meest flexible van de twee partijen ben, mag jij de rommel opruimen door een workaround te implementeren. Kan ook zijn dat de business iets vergeten is, maar het wel heel erg belangrijk vindt, zelfde effect.

Dat refactoren en 'grote schoonmaak' klinkt in mijn oren een beetje als (wat hard verwoord):
- het design deugde niet
- We accepteren troep code en geven niets om Q&A (it compiles, let's ship it)
- Waar komt die ellende vandaan en waarom vinden we het normaal dat dit ontstaat?

Ik denk dat je een te rooskleurig beeld hebt van softwareontwikkeling en je vergeet dat er met software verkopen/gebruiken gewoon veel geld verdiend wordt, en een dag eerder in productie is gewoon bikkelharde cash. Dus er wordt behoorlijk powerplay gespeeld als zaken in productie moeten, en dan heb je technisch soms wat op te offeren. Dat is het echte leven in de IT. Ik zou deze blogpost eens lezen over hoe het er echt aan toe gaat: https://www.stilldrinking.org/programming-sucks

[Q]

Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there

Ben ik werkelijk dan de enige gek die dat soort opdrachten niet point blank accepteert en om de tafel gaat om te snappen wat werkelijk de bedoeling is? En wat werkelijk prioriteit heeft en wat kan wachten?

Waarom zou je dit soort kunstmatige opjaag tactieken accepteren?

[Q]

Perfectie is nooit het doel, wat dat ook mag betekenen. Het doel is om de gewenste functionaliteit op te leveren, rekening houden met zaken als stabiliteit/robuustheid misschien. (de niet-functionele shizzle).

Ik heb in die context nu een beetje het gevoel dat je nu schets tat als 'perfectie' niet is bereikt en dat als je verder gaat dat je dan TD opbouwt maar ik kan niet in dat beeld mee gaan, ik denk dat dit in de praktijk niet het punt is.

Voor wat betreft rommel: prachtige term. Ik jij of een 3e partij (dat rijmt) levert rommel op. De schipper hier aan wal zegt dan: als je rommel van anderen gaat lopen fixen, dan is dat wat je doet. Rommel van anderen fixen. Maar dat is geen Technical Debt. Dat is gewoon dat iemand faalt om te leveren en daardoor gaat het mis. Jij bent instaat om het recht te trekken, gelukkig, maar nogmaals: geen TD.

Misschien ben ik te rooskleurig, maar misschien ben ik ook (te) kritisch. Ik heb altijd erg veel vragen in deze context. Zoveel vragen. Ik ben een lastpost. Ik kan niet stoppen.

Als je een dag eerder in productie wilt om een extra dag omzet te draaien, dan denk ik. Waarom niet een week eerder? Of een Maand? Waar komt die druk vandaan, en slaat deze werkelijk ergens op?

Want zo kun je wel blijven doorgaan. Die ene dag extra omzet, moet het daar van afhangen, is die rotcode dat echt waard?

En is die code echt zo rot? Is het echt zo'n probleem? Als slechte code schrijven efficiënter is dan goede code, heb je dan niet een veel groter probleem. (misschien een terzijde)

Hoe kan het dat je 'het zo ver hebt laten komen' (waarbij je hier een organisatie betreft) en is dat die code het probleem ofwel je organisatie/business processen?

Maar ok ik ga mee in je scenario for the sake of argument.

Je schrijft een stukje rotcode om het later opnieuw te schrijven maar dan netjes. Een versimplede vorm van wat mensen Technical Debt noemen. Je creëert een schuld en je lost hem in.

Maar dat kan niet. Geld kun je lenen maar tijd niet. Borrowing time is bullshit wat mij betreft.

Tijd vernietig je gewoon, die tijd komt nooit meer terug. De slechte code die je nu schrijft is een permanente opportunity cost. Want die tijd krijg je nooit meer terug. Want als je die tijd pakt, gaat dat ten koste van nieuwe opportunities die je anders had kunnen realiseren.

Iedere dag dat je werkeloos bent is een dag dat je geen salaris ontvangt en dat krijg je nooit meer terug, dat kun je nooit meer inhalen of goedmaken.

Je kunt hooguit weer aan het werk gaan. Je kunt hooguit weer code fixen. Maar het verlies is permanent.

Of dat verlies staat tegenover een winst op ander vlak, misschien ik heb zo mijn twijfels, maar dan nog is het niets meer dan een business afweging.

Het concept van technical debt vind ik een vreemd, en gevaarlijk idee. Ik moet dit eens beter uitwerken in een mooie blogpost, dit is wat hardop nadenken.

[phYzar]

De afgelopen vier weken hebben X en Y gewerkt aan een nieuwe feature voor hun organisatie. Daarbij liepen zij tegen technical debt aan. Na vier weken staan er acht stippen (iedere stip is een halve dag werk) op de sticky note. Tijdens het ontwikkelen van de feature is er dus vier dagen aan tijd verloren gegaan.

Valkuil is wel enige subjectiviteit: X en Y houden niet zo van techniek Z, want ze houden niet van dat wat ze niet zelf gemaakt hebben, dus Z is gelijk voorzien van veel stippen. Maar is de door hun gedroomde nieuwe methode "Zhipstercloud" wel sneller en beter dan classic Z? Of simpeler gezegd: gaan ze een lekke band vervangen door een lekke band?

[AlphaRomeo]

Precies dit, sommige zaken zijn ook voortschrijdend inzicht. Jaren geleden heb je op wat toen bekend was keuzes gemaakt die je met de kennis en technieken van vandaag anders zou maken. Met name nieuwe ontwikkelaars die die historie niet kennen schuiven dat later dan af op technical dept alsof men destijds de binnenbocht heeft willen nemen.

Ook de reacties hier over een 'goede architectuur' die alles op zou lossen gaan daarmee niet op. Je kunt geen architectuur maken voor wat je nog niet weet dat je ooit bij gaat bouwen. Het bouwen van software lijkt op het bouwen van een huis, alleen wordt er constant op doorgebouwd omdat sales nieuwe 'features' aan het huis blijft verkopen. Je kunt niet je architectuur zo inrichten dat het voorbereid is op alle toekomstige mogelijke features, en als je dat wel kunt is je architectuur veel te complex voor het doel. Je hebt nu bijvoorbeeld een tweekapper staan met een architectuur voor een wolkenkrabber met zwembad op het dak. Als je na jaren bouwen van die tweekapper een flatgebouw hebt gemaakt zit je nog steeds met wat oude fundering van het oorspronkelijke huis, dat is normaal, het is niet zo dat je oorspronkelijk verkeerde keuzes hebt gemaakt. Je hebt toen naar eer en geweten de juiste keus gemaakt voor wat bekend was op dat moment.

[tijmenwierenga]

Ik zeg altijd: naar je werk neem je je best practises mee en zet je bewezen methodieken in. Wanneer je de impact niet kan inschatten moet je er niet zomaar aan beginnen.

Uiteraard blijft software development een relatief subjectieve discipline, maar wanneer je een goede impact/effort analyse hebt gedaan zou je voornamelijk issues oplossen die grote impact hebben en relatief weinig effort kosten.

[M14]

Inmiddels heb ik bij een paar kleinere en grotere bedrijven gewerkt (embedded sw) Mijn ervaring:
Bij kleinere bedrijven wordt niet verder gekeken dan het opleveren. Er wordt zelden tot niet de stap gemaakt om beter te documenteren, te testen of zaken generiek/herbruikbaar te maken, want "het kost alleen maar tijd en dus geld, wat je nooit terug ziet". Dit in combinatie met slecht tijd inschatten en dus altijd vechten om op tijd op te leveren.

Bij grotere bedrijven wordt eerder een kosten/baten analyse gemaakt betreft het herbruikbaar maken. De discussie wie de extra uren gaat betalen wordt dan ook snel een onderdeel van het spel. Dus dat is ook niet direct garantie op succes. Wel wordt er veel meer aandacht besteed aan plannen en testen.

[Wraldpyk]

Ik heb een vergelijkbare ervaring inderdaad. Bij kleine bedrijven is de oplossing, schijnbaar, om technical debt op te lossen door om de 3-5 jaar ofzo een rewrite te doen van alles omdat het een bende is geworden (duh).

Sommige bedrijven (kan even geen link vinden, dus even vanuit geheugen) maken er als policy van om dit structureel te doen. Elke 2-3 jaar een nieuwe versie maken, oftewel een volledige public-facing applicatie bouwen en daar vooral onderhoud op plegen, en dan in de achtergrond beginnen met plannen van een nieuwe versie waar de nieuwe wished-for features in komen, en dan heb je ook geleerd van de vorige versie(s). Deze strategie is zo slecht nog niet eens imho.

[JorzoR]

Bij kleine bedrijven is de oplossing, schijnbaar, om technical debt op te lossen door om de 3-5 jaar ofzo een rewrite te doen van alles omdat het een bende is geworden

Bij kleine bedrijven is groei vaak belangrijker, dat is de drijfveer achter beslissingen. Dat betekent snel nieuwe features voor je gebruikers eruit stampen. Als je daar langer over doet, kan je concurrent voorsprong krijgen. Dus punten waar niet direct waarde in zit voor de eindgebruiker, worden inderdaad naar achter geschoven. Vaak wordt er ook in kleinere teams gewerkt dus moet je goed omgaan met schaarste van expertise.

Wat ook meespeelt is dat kleinere bedrijven over het algemeen hun idee nog moeten valideren. Dat zorgt er dus ook voor dat features snel gemaakt worden en technical debt oploopt.

Dat is wat ik de afgelopen jaren zie met mijn freelance dev werkzaamheden bij heel wat bedrijven.

Allemaal niet heel raar. Het moet alleen in de juiste context geplaatst worden.

[Reactie gewijzigd door JorzoR op 22 juli 2024 21:26]

[M14]

Ik denk dat alles begint met goede architectuur. Dan is er overzicht welke onderdelen beschikbaar zijn en met welke interfaces deze aan elkaar hangen.

[supersnathan94]

Is ook zo, maar als je iets nieuws gaat maken wat nog eerder is gedaan dan is een goede architectuur niet triviaal en vaak pas te valideren achteraf.

Vooral in grote projecten waar weer eens het wiel opnieuw wordt uitgevonden is dat lastig.

Dit is dan ook vaak de reden dat aanbestedingen toch langer duren dan gepland. Die laatste 5% blijkt dan toch een volledig andere aanpak te vergen.

[Crazy D]

Inmiddels heb ik bij een paar kleinere en grotere bedrijven gewerkt (embedded sw) Mijn ervaring:
Bij kleinere bedrijven wordt niet verder gekeken dan het opleveren. Er wordt zelden tot niet de stap gemaakt om beter te documenteren, te testen of zaken generiek/herbruikbaar te maken, want "het kost alleen maar tijd en dus geld, wat je nooit terug ziet". Dit in combinatie met slecht tijd inschatten en dus altijd vechten om op tijd op te leveren.

Het is ook de vraag of de verwachting is of er nog veel aanpassingen aan gedaan moeten worden. Heel simpel: als je 10 projecten hebt en je kiest de praktische snelle ontwikkeling, waardoor het misschien lastiger onderhoudbaar is. Maar, bij maar 1 project loop je er tegen aan, is de vraag of de tijd die het dan extra kost opweegt tegen de extra tijd die het kost als je bij alle projecten alles zo generiek mogelijk met ladingen interfaces en andere best practices gaat werken. In mijn ervaring is dat vaak niet het geval.

Als de verwachting wel is dat er doorontwikkeld moet worden, is het een ander verhaal. Dan zou je er in de basis al veel meer rekening mee moeten houden.

[Sandor_Clegane]

Mooi verhaal, alleen wat ik mis is hoe je technical debt ( mooi Nederlands ) leert herkennen want daarin zit nu net de crux. Ik snap wel dat het geen exacte wetenschap is maar een praktijkvoorbeeld over hoe het te herkennen is wel een goede/leerzame toevoeging lijkt me. Nu is het meer een verhaal over hoe je het zichtbaar maakt, maar dat veronderstelt dat je je domein al dermate begrijpt dat je de pijnpunten goed kunt benoemen en dit is vaak nu net waar het venijn zit.

Met name omdat technical debt alleen maar, nou ja vaak, met "2020 hindsight" zichtbaar wordt.

[Mike2k]

Hoe je technical debt kunt herkennen:

Een makkelijk voorbeeld:
Ik heb een project gedaan bij de AVR. Daar hebben ze een aantal AVI's (Afval Verbrandings Installaties) en een grote weegbrug.

Deze systemen zijn allemaal een jaar of 20/30 oud. De software die daar destijds voor is gemaakt draait veelal op WinXP/Server 2003. De weegbrug software draaide op linux.

Je kan de AVI niet zomaar vervangen aangezien dat gigantisch veel geld kost. Het OS wordt niet meer ondersteunt en je kunt ook niet verder met nieuwe technieken.

[Marcade]

Hmm weet niet zozeer of je *dat* technical debt kan noemen; sinds 20/30 jaar geleden misschien de software well goed geschreven & opgeleverd was.

Bij technical debt, denk ik meer aan bewuste beslissingen die tijdens ontwikkeling worden genomen, om tijd te winnen ten koste van kwaliteit. Maar waar je later over struikelt als je nieuwe functionaliteiten wilt toevoegen, of bugs probeert op te lossen.

In jouw situatie, zit je al in de support fase van het product; aangenomen dat het product goed functioneerde, 20/30 jaar geleden .. was er op dat moment geen technical debt .. met de tijd is het product gewoonweg verouderd en management is te koppig om het te vervangen/vernieuwen.

[Sandor_Clegane]

Dank jullie voor het maken van mijn punt.

@Mike2k ik sluit me wel een beetje aan bij @Marcade want ik neem aan dat ten tijde van het ontwikkelen, het OS een doordachte keuze is geweest. Het bijhouden van de software lijkt me niet echt technical debt, dat is gewoon inherent aan software. Maar ook dit is weer afhankelijk van hoe er tegen de software wordt aangekeken, doet het wat het moet doen, is het feature complete en zo ja, dan is er eigenlijk niet zoveel aan de hand. Natuurlijk zit je wel met een OS wat niet meer ondersteund wordt, maar als er de juiste voorzorgsmaatregelen zijn genomen omtrent de infra ( firewall, afschermen etc. etc. ) dan is het wel te begrijpen dat het "goed genoeg" is.

Nu zullen er een hoop zijn die zeggen dat je altijd alles op een OS moet hebben draaien dat ondersteuning geniet, maar zoals zo vaak blijkt de echte wereld wat weerbarstiger.

[Reactie gewijzigd door Sandor_Clegane op 22 juli 2024 21:26]

[graey]

Je zou wel kunnen stellen dat er misschien technical debt is omdat de systemen blijkbaar zo geïntegreerd zijn dat alleen de gedateerde PC-hardware vervangen niet kosteneffectief kan. Als alles enigszins modulair zou zijn, zou je kunnen zeggen: we schrijven een nieuw setje software voor Windows 10/moderne Linux ondersteuning, vervangen de PC-componenten en we kunnen weer 10-20 jaar.

[Sandor_Clegane]

Dat is ook wat ik bedoelde met: als je maar genoeg uitzoomed dan kun je alles er wel onder scharen.

[Mike2k]

Ik ben het ook eens met jullie beiden. Destijds zal het goed gefunctioneerd hebben.

met de tijd is het product gewoonweg verouderd en management is te koppig om het te vervangen/vernieuwen.

Maar zorgt dat er dan niet ook voor dat je een technical debt krijgt ?

Moet de technical debt perse veroorzaakt worden door beslissingen tijdens het ontwerp van het systeem/software ?
Wellicht wilde het management in dit geval geen support contract of iets dergelijks waardoor de uiteindelijke uitkomst hetzelfde is toch ?

[mphilipp]

Het bijhouden van de software lijkt me niet echt technical debt, dat is gewoon inherent aan software.

Nou...dat is ook niet altijd waar. Heel toevallig ken ik die situtatie bij AVR ook, en heb ook een keer een collega bijgestaan in een onderzoek naar de mogelijkheden van het upgraden van wat Oracle software bij Unilever. Het is al heel lang geleden, dus nu kan ik het wel uit de doeken doen.
Unilever produceert ons aller Calvé pindakaas. Dat gebeurde toen in ieder geval in Rotterdam; geen idee of ze dat nog steeds doen. Een Oracle Forms applicatie stuurde de machines aan. Letterlijk. Er was een API in C en je kan in Oracle Forms ook C opnemen via een pre-compiler. Dat hadden ze gedaan. De hele oplossing draaide op Oracle 8 of 9 dacht ik op een Solaris machine. Oud, toen al. Toen gingen zij het beheer uitbesteden, en de beheerpartij weigerde deze machine mee te nemen omdat het al lang en breed out of support was. Samen met mijn collega moesten wij kijken of en hoe dit naar een supported versie over kon. Dat ging dus niet (zomaar) vanwege die C code. Inmiddels was het bedrijf dat de machines maakte (en dus ook de API) overgenomen door Siemens en die machines waren ook al lang en breed verouderd. Dus upgraden kon niet, tenzij je zelf een nieuwe API zou schrijven. Overigens was dat hele Oracle Forms al zowat uitgefaseerd en door Webforms vervangen. Ik geloof dat het nog steeds wel bestaat, maar het wordt nauwelijks meer gebruikt.

Daar is mijn bemoeienis gestopt, en ik heb geen idee wat ze gedaan hebben. Maar als je het hebt over technical debt is dit wel een goed voorbeeld. Dat je op moment x iets maakt dat op dat moment een goed idee is of lijkt, is één ding. Maar je moet dan wél de boel up to date houden. Ik heb vaak genoeg klanten meegemaakt die pas gingen upgraden als het niet anders meer kon. En dán ben je een beetje laat en kost het je veel meer tijd en moeite. Ik heb bij een klant zelfs een keer meegemaakt dat we niet eens meer de installer van Oracle konden starten omdat ze 2 goldpacks (HP UX) achter liepen. Dat betekent dus dat ze 2 belangrijke updates niet hebben gedraaid. Gelukkig was het maar één server, maar het was wel een behoorlijke issue, want er draaide van alles op. Je moet dus 1 voor 1 al die software gaan nakijken of die wel op de nieuwe versie van het OS kunnen werken, etc, etc.

Nee, technical debt is echt een ding, en de boel up to date houden hoort daar zeer zeker bij. Maar het kost geld en is vervelend, dus slaan ze het maar over. Behoorlijk kortzichtig, want het komt altijd terug om je in de staart te bijten. Gegarandeerd.

[Q]

Wat je hier schets heeft wat mij betreft niets met technical debt te maken. Dit is puur de keuze om software niet up-to-date te houden zodat het onderhouden kan worden.

Dat ergens iets draait op MS-DOS op een 386 DX40 is geen 'technical debt'. Dat is gewoon een afgewogen business risico. Een keuze om te besparen, waarbij je een bepaald risico neemt. Wat soms tot grote problemen kan leiden, zeker maar daarom noemen we het ook een risico.

Ik krijg het gevoel dat sommige mensen 'business risico' hernoemen naar technical debt.

Toen gingen zij het beheer uitbesteden

Ah, veranderende omstandigheden!

Tot het moment van uitbesteding was er eigenlijk - zoals ik het lees - niets aan de hand. Oud wil niet zeggen niet-functioneel.

Ik ga die keuzes die gemaakt zijn niet persé verdedigen maar ik kan dit allemaal geen Technical Debt noemen. Hooguit achterstallig onderhoud. Maar dat is dan precies dat en niet meer: gewoon achterstallig onderhoud.

[mphilipp]

Tot het moment van uitbesteding was er eigenlijk - zoals ik het lees - niets aan de hand. Oud wil niet zeggen niet-functioneel.

In principe niet nee, het werkte prima. Alleen is dat net als een hele oude auto. Die kun je ook met wat TCL op de weg houden. Totdat er een onderdeel stuk gaat dat nergens meer te krijgen is. Zo ken ik een bedrijf dat remote beheer doet en die onderdelen voor een VAX-VMS op voorraad moest houden voor een klant. Die support was ontzettend duur. Ik vermoed dat het goedkoper was geweest om het tijdig te upgraden. Ze draaiden ook nog op Oracle 7...

Ik ga die keuzes die gemaakt zijn niet persé verdedigen maar ik kan dit allemaal geen Technical Debt noemen. Hooguit achterstallig onderhoud. Maar dat is dan precies dat en niet meer: gewoon achterstallig onderhoud.

Dat is gewoon een semantische discussie. Taalkundig is het gewoon hetzelfde natuurlijk. Achterstand of schuld komt op hetzelfde neer. Je creëert problemen door niet tijdig te upgraden. Nieuwe versies van een OS hebben vaak meer mogelijkheden om met nieuwere technologieën om te gaan, of zijn gewoon beter/sneller. Kan zijn dat je daar geen behoefte aan hebt, maar als het gaat om kritische bedrijfsprocessen (zo zou ik de productie van pindakaas wel willen noemen) is het aan te bevelen.

Ik ken een andere situatie waar een bedrijf bewust op oude spullen bleef draaien (MS-DOS in dit geval) omdat zij een geautomatiseerd magazijn hadden met robot-heftrucks. Die werkten met een oude MS-DOS PC, die in de Oracle database keek voor nieuwe opdrachten. Helaas staakte Oracle op enig moment de ondersteuning voor MS-DOS dus kon hun nieuwe Oracle 7 of 8 database niet meer praten met de MS-DOS bakken. Toen hebben zij de source gekregen/gekocht van die driver onder MS-DOS en 'm zelf maar gecompileerd. De PC's omzetten naar Windows was geen optie. En in die tijd was Linux nog niet zo populair, anders had men dat gedaan denk ik. Tegenwoordig had het op een Pi kunnen draaien

[Q]

In principe niet nee, het werkte prima. Alleen is dat net als een hele oude auto. Die kun je ook met wat TCL op de weg houden. Totdat er een onderdeel stuk gaat dat nergens meer te krijgen is. Zo ken ik een bedrijf dat remote beheer doet en die onderdelen voor een VAX-VMS op voorraad moest houden voor een klant. Die support was ontzettend duur. Ik vermoed dat het goedkoper was geweest om het tijdig te upgraden. Ze draaiden ook nog op Oracle 7...

Maar dat is dan puur de business risico afweging. Ze maken een keuze en soms komt men er niet mee weg. Het kan zeker heel verkeerd aflopen, maar dat is nog steeds geen technical debt. Dat is gewoon het nemen van een business risico. En dat risico wordt serieus genomen: zie maar hoe er onderdelen op voorraad worden gehouden. Ik deel verder je analyse over wat mogelijk verstandiger zou zijn geweest.

Maar ik lees hier niets over technical debt.

Dat is gewoon een semantische discussie. Taalkundig is het gewoon hetzelfde natuurlijk. Achterstand of schuld komt op hetzelfde neer. Je creëert problemen door niet tijdig te upgraden. Nieuwe versies van een OS hebben vaak meer mogelijkheden om met nieuwere technologieën om te gaan, of zijn gewoon beter/sneller. Kan zijn dat je daar geen behoefte aan hebt, maar als het gaat om kritische bedrijfsprocessen (zo zou ik de productie van pindakaas wel willen noemen) is het aan te bevelen.

Mee eens: ik denk dat dit zeker een semantische discussie is, maar wel een belangrijke. Ik vind dat de term 'Technical Debt' wordt misbruikt in vrijwel alle situaties om iets goed te praten wat niet goed te praten valt (op die manier). Mensen gebruiken die term om onder verantwoordelijkheid uit te komen, waar ik mijn betoog mee begon.

Dus die semantische discussie is super belangrijk voor de perceptie. Kom je met onzin weg, of neemt iemand gewoon zijn/haar verantwoordelijkheid en gaan we kijken hoe we 'fouten' in de toekomst kunnen voorkomen. Een eerlijke introspectie om te verbeteren.

Alles wat je hier noemt is business risico, geen technical debt. En management neemt dat business risico. Want dat is wat je in die positie ook heel veel doet: risico managen. Of ze dat goed doen is een ander verhaal.

Maar het is verdomd duidelijk dat er risico wordt genomen en wie dat risico neemt, niemand kan zich achter vage terminologie verschuilen.

Ik vind je voorbeelden trouwens wel leuk om te lezen, bedankt daarvoor.

Ik ken een andere situatie waar een bedrijf bewust op oude spullen bleef draaien (MS-DOS in dit geval) omdat zij een geautomatiseerd magazijn hadden met robot-heftrucks. Die werkten met een oude MS-DOS PC, die in de Oracle database keek voor nieuwe opdrachten. Helaas staakte Oracle op enig moment de ondersteuning voor MS-DOS dus kon hun nieuwe Oracle 7 of 8 database niet meer praten met de MS-DOS bakken. Toen hebben zij de source gekregen/gekocht van die driver onder MS-DOS en 'm zelf maar gecompileerd. De PC's omzetten naar Windows was geen optie. En in die tijd was Linux nog niet zo populair, anders had men dat gedaan denk ik. Tegenwoordig had het op een Pi kunnen draaien

Tja, ik vind het fantastisch zo'n verhaal, ik smul er van. Maar je weet inmiddels wel hoe ik hier naar kijk

[J_van_Ekris]

Dat ergens iets draait op MS-DOS op een 386 DX40 is geen 'technical debt'. Dat is gewoon een afgewogen business risico. Een keuze om te besparen, waarbij je een bepaald risico neemt. Wat soms tot grote problemen kan leiden, zeker maar daarom noemen we het ook een risico.

Soms is er ook geen alternatief. Alhoewel je misschien moet investeren om dat weer te krijgen (ik ken een club die de boel minimaal virtualiseerde, om zo hardwarefalen te voorkomen).

Ik krijg het gevoel dat sommige mensen 'business risico' hernoemen naar technical debt.

Dat ben ik met je eens. Dit soort vage termen worden te pas en te onpas gebruikt, en dan ben je helemaal los. Daarom heb ik liever dat men de bullshit-bingo opbergt en het gewoon zegt waar het op staat.

[mae-t.net]

OS'sen lopen bijna altijd uit ondersteuning gedurende de levensduur van je product, zeker als het om dure installaties gaat. Er zou dus eigenlijk vantevoren al van uit moeten worden gegaan dat dat niet uit mag maken, of dat je geen "consumenten/server OS" draait als dat echt uitmaakt. Degenen die zeggen dat je alles altijd op een ondersteund OS moet draaien, hebben kennelijk geen inzicht of ervaring met een hoop industriële scenario's. Linux heeft dan nog het voordeel boven Windows dat in-house of ingehuurde 3rd party ondersteuning eigenlijk de norm is, zodat je zelfs voor oude versies nog beperkte ondersteuning kunt hebben.

[J_van_Ekris]

OS'sen lopen bijna altijd uit ondersteuning gedurende de levensduur van je product, zeker als het om dure installaties gaat. Er zou dus eigenlijk vantevoren al van uit moeten worden gegaan dat dat niet uit mag maken, of dat je geen "consumenten/server OS" draait als dat echt uitmaakt. Degenen die zeggen dat je alles altijd op een ondersteund OS moet draaien, hebben kennelijk geen inzicht of ervaring met een hoop industriële scenario's.

Ik heb laatst voor een klant op industriele PLC's geprobeerd ondersteuning af te dwingen tot 2038, en niemand geeft thuis. Ze garanderen hooguit 10 jaar spare parts, en een last buy om je voorraad van spare parts aan te vullen, maar verder gaat men niet. Dus elke keuze is een belabberde in dat opzicht.

[Garyu]

Misschien een ander voorbeeld. We hebben een simulatie-omgeving waarin we onze (VHDL)-code testen. Deze omgeving is een tiental jaar geleden in VHDL geschreven. Deze simulatie-omgeving niet makkelijk aan te passen. Als we het nu zouden willen aanpassen, is het het beste om direct over te stappen naar UVM/SystemVerilog. Echter betekent dat (tien)duizenden ontwikkeluren weggooien en opnieuw beginnen.

We weten dat dit ooit moet gaan gebeuren, maar wanneer is het juiste moment om dit te gaan doen? Hoe lang borduur je nog voort op het (achterhaalde, dure) concept, en hoe maak je die keuze -als organisatie- op het juiste moment?

[Sandor_Clegane]

Tja, was VHDL toen de juiste keuze? Zo ja, dan is het meer een kwestie van toevallig op het verkeerde paard te hebben gewed. Dat is gewoon inherent aan keuzes maken lijkt me.

Beetje hetzelfde als source control systemen, heb je lopen investeren in een source control oplossing komt GIT om de hoek en dat is bijna de de facto standaard geworden.

Ik weet niet of het technical debt is, als je maar genoeg uitzoomed kun je er alles wel onder scharen lijkt me.

Onder technical debt versta ik meer software waaraan actief gewerkt wordt en waar een aantal keuzes uit het verleden het huidig ontwikkel werk bemoeilijken, niet een complete rewrite van de software. Maar ja dit is ook weer open ter interpretatie.

[Garyu]

Die keuze was toendertijd wel terecht als quick-and-dirty oplossing, maar daar is te lang op doorgewerkt waardoor het steeds logger en complexer wordt. De drempel om dan te switchen wordt met de tijd steeds groter en groter. En uiteindelijk moet je om.

Bij elk nieuw project waar je niet wisselt, wordt die "wall of technical dept" groter, maar in elk individueel project kán die keuze niet principieel gemaakt worden, omdat die muur al zo groot is.

[Sandor_Clegane]

Dit klinkt meer als de "sunk cost fallacy": "we hebben er al zoveel in geïnvesteerd, we moeten door."

https://nl.wikipedia.org/wiki/Sunk_costs

Niet om moeilijk te doen hoor.

[Garyu]

Hehe, nee, dat zou betekenen dat het "niet willen weggooien" het argument is om door te gaan. Het argument is echter dat de delta-kosten van "nog een keertje verder met VHDL" per keer veel lager zijn dan de kosten van een compleet re-design.

[Sandor_Clegane]

Uhm nee, de hoeveelheid geïnvesteerde tijd en geld maakt dat je ermee door gaat.

[Garyu]

Nitpicking, I know... maar er is een duidelijk verschil tussen een dure maar rationale beslissing om ergens mee door te gaan ("sunk costs") en een irrationele beslissing ("sunk costs fallacy") .

[Sandor_Clegane]

True, de link klopte wel.

[KNed]

Dit vind ik geen technical debt. Dit is puur de omgeving waar je mee te maken hebt. Randvoorwaarden.

Technical debt heeft te maken met keuzes die je tijdens ontwikkeling maakt en je later tijd dus geld kosten bij andere ontwikkelingen.
Zoals een snelle, lelijke fix die echter later doorontwikkeling in de weg staat.

Het herkennen van technical debt is al een belangrijk punt. Het is namelijk nog erger als je niet doorhebt dat je technical debt aan het veroorzaken bent.

[Q]

Ik vind dat helemaal geen technical debt.

Technical depth impliceert dat je heel bewust een lening neemt. (Een lening nemen doe je bewust). En dat je die lening later dus gaat terug betalen (met rente).

Dat is hier helemaal het geval niet. Dit verhaal met de AVR is puur gewoon verwaarlozing. Het is functioneel, we doen verder geen enkele onderhoud, het werkt toch? En dat die Windows versies niet worden ondersteund, dat maakt ze verder niets uit.

Maar wat is hier het probleem, het is oud maar wat dan nog? Als het al 30 jaar werkt?

[Sandor_Clegane]

Debt Niet om lullig te doen hoor.

En nu we het toch over Debt hebben, de man van "Debt: The first 5000 years" is overleden.

RIP David Graeber. 2020 is een sucky jaar.

[Reactie gewijzigd door Sandor_Clegane op 22 juli 2024 21:26]

[Q]

Stom, thanks!

[Mike2k]

Dit verhaal met de AVR is puur gewoon verwaarlozing

Verwaarlozing is toch ook een lening ? je spaart geld/manuren uit door je systemen niet te updaten, je software niet mee te ontwikkelen etc waardoor je uiteindelijk gigantisch achter loopt.

In dit geval zou de technical debt kunnen zijn dat het nu, bij problemen, ontzettend moeilijk is om een systeem te vervangen of onderhouden.

Bijvoorbeeld een Windows 2003 iso'tje is wat lastiger te vinden, je kan niet zomaar een willekeurige pc van de plank pakken etc...

[J_van_Ekris]

Klopt, wat je vaak ziet is dat je een krankzinnig duur apparaat koopt met de bijbehorende software, en dan vertikt de leverancier support te leveren na x jaar. De software is ooit door een stagaire in elkaar geknutseld met Delphi of andere antieke meuk, en dan ben je als klant aan de goden overgeleverd. Machientje laten draaien en hopen dat hij niet stuk gaat is het enige wat je kan doen.

Heb het bij een klant ook gehad: hele installatie hing uiteindelijk van een tool af, wat niet meer gesupport werd, en dus de upgrade naar een nieuwe versie van Unix en Oracle tegenhield. En bovendien weigerde HP de gebruikte Unix variant nog te leveren, en Oracle de database (want te oud). Waren een spannende paar maanden.

[J_van_Ekris]

Grappig, het illustreert eigenlijk voornamelijk dat je een gedegen support constructie in je contracten verwerkt wilt hebben. Heeft niets met Technical Debt te maken.

Tja,

In Nederland zijn contracten altijd eindig, meestal 8 of 10 jaar. En dat is een mooi moment voor een leverancier om te zeggen dat het product niet meer ondersteund wordt, en er dus geen nieuw contract meer gaat komen. Enorme streek van zo'n leverancier, maar het gebeurt vrij veel. En dan zit je ineens op een platform wat niet meer ondersteund wordt door de leveranciers. Dat is de realiteit.

[Q]

Mee eens hoor, maar vaak kun je gewoon een upgrade kit kopen voor iets teveel geld maar net niet teveel geld om zelf te gaan lopen prutsen. En de derde optie: niets doen en het er op gokken wordt dan veel gekozen.

Heeft niets met Technical Debt te maken. Puur business risico afweging.

[bzzzt]

Die business value case hoor ik wel vaak, maar wordt er dan ook rekening gehouden met de kosten wanneer het genomen risico (vrijwel onvermijdelijk) werkelijkheid wordt? Als je een afvalverwerkingsinstallatie een week dicht moet gooien omdat een DOS PC is gecrasht kost dat meer dan dat je vooraf iemand eens een backup plan had laten bedenken.

[Full_hyperion]

Ik vind dat helemaal geen technical debt.

Technical depth impliceert dat je heel bewust een lening neemt. (Een lening nemen doe je bewust). En dat je die lening later dus gaat terug betalen (met rente).

Grote leningen vaak wel, maar als je kan rood staan op je betaalrekening, kun je ook gewoon een lening aangaan door de boodschappen bij de supermarkt te betalen.

Zo gaat het ook tijdens de ontwikkeling, soms neem je een bewuste keuze om iets niet of snel te doen, soms sta je er niet genoeg bij stil en gaat het onopgemerkt.

[Full_hyperion]

Tja, ik vind dat we nu teveel aan het steggelen zijn over een analogie.

Misschien moeten we er nog een vergelijking met auto's bijhalen, zo hoort dat toch?

En als je ergens niet goed rekening mee hebt gehouden, dan is dat niet meer dan dat: je hebt gewoon een fout gemaakt.

Ga dat niet zitten verbloemen door het heel 'deftig' technical debt te noemen, maar erken dit, en fix de shit. We hoeven er verder geen drama van te maken, iedereen maakt fouten. Maar verbloem dat niet, vind ik.

Nouja, je mag het van mij best anders noemen, maar de manieren om er mee om te gaan blijven redelijk hetzelfde. De tijd nemen om het te fixen, of het niet netjes fixen en er ergens anders omheen werken, met extra tijd/kosten als gevolg.

[Q]

Verder mee eens.

[Hans1990]

Dit klinkt als legacy support. Een klant gaat niet elke 5 jaar een nieuwe machine kopen omdat de computer daarin een verouderd OS draait. Een klant wil ook niet elke 5 jaar betalen voor een "retrofit"-kit, mocht de fabrikant die al kunnen maken, om de computer enkel te upgraden. Dit is mijn inziens een natuurlijk verloop van industriele machines die embedded computers gebruiken.

Je kan je ook afvragen hoeveel features en werk er aan zo'n machine zit. Moet je nieuwe features toevoegen, bv veiligheid of wet/regel geving aanpassen? (Legacy support) Of moeten de prestaties van de machine omhoog? (Product Engineering)

Dat laatste zou ik inderdaad gebruik van moderne technieken en innovatieve algoritmes/sensors/etc.etc. toejuichen. Dat eerste moet je niet teveel complexiteit toevoegen. Als een machine een extra safety cut-out nodig heeft, dan voeg je toe en laat je de verdere werking zoveel mogelijk intact.

Het is maar wat het bedrijf wil. Ik heb een tijdje bij een automatiseerder gewerkt waar klanten verwachten nog steeds de allernieuwste software updates te krijgen (software was gratis), en ook de verwachting hadden dat deze nog steeds alle nieuwe features tegelijk konden draaien. Ze hadden immers toch de extra ECU's en kabelbomen op hun landbouwmachine gezet toch?!
Op computer hardware van 15 jaar oud ging dat simpelweg niet. Toch besloot het bedrijf mee te gaan met de klant (IMO inschattingsfout bij de (technische)verkoop), waardoor je als techneut enkel maar kan zuchten..

[Reactie gewijzigd door Hans1990 op 22 juli 2024 21:26]

[bzzzt]

Een klant wil toch wel een ondersteunde hardware+software combinatie? En wat zou er met apparaten die decennia meegaan mis zijn met zo'n 'retro kit' oplossing als je daarmee de levensduur van zo'n apparaat kan verlengen?

[tijmenwierenga]

Bedankt voor je feedback .

Ik zie technical debt als belemmeringen die vertragend werken bij het realiseren van je doelen. Persoonlijk herken ik technical debt letterlijk als verloren tijd. Soms is het een stuk software waarbij je de juiste abstracties mist, waardoor het moeilijk aan te passen is. Soms zijn het ontbrekende tests, waardoor je uren bezig met met het oplossen van edge cases. Het is net wat je zegt geen exacte wetenschap, maar zodra triviale dingen onredelijk veel tijd kosten ben je waarschijnlijk iets op het spoor.

[Q]

Strikvraagje:

Zijn ontbrekende tests technical debt of was het gewoon een kwestie dat het werk niet af was (als tests wel vereist waren). Want dan hoef je de term td niet te gebruiken, maar kun je gewoon zeggen dat het werk niet af was

Als de code geschreven is in een tijd dat dit nog geen eis was, dan is dat geen debt. Want terug in de tijd toen is nooit bewust een 'lening' genomen op de toekomst. In die context is het ontbreken van tests dus gewoon een 'gegeven' en onderdeel van het werk.

De keuze zou ook gemaakt kunnen worden om een feature freeze te houden en een periode alleen tests schrijven voor de code als deze er nu niet is. Of je doet het wanneer je er tegenaan loopt, de kosten lijken mij vergelijkbaar.

Maar voor mijn gevoel zie ik hier geen case voor 'technical debt'.

[tijmenwierenga]

Code die vandaag geschreven wordt moet naar mijn mening automatische tests hebben. Ik beschouw het werk anders als niet af.

Soms neem je bewust een lening voor snellere oplevering, maar soms bouw je die lening ook onbewust op. We programmeren allemaal met de kennis die we vandaag de dag hebben en ooit zal die kennis achterhaald zijn. Wanneer de tijd je inhaalt en je merkt dat de code je tegenhoudt om effectief te doen wat je wilt bereiken kun je die code in mijn optiek dan markeren als technical debt.

Voor mij is het onbelangrijk of de lening bewust of onbewust is genomen. Ik wil in de toekomst zo efficiënt mogelijk mijn doelen bereiken.

[Q]

Soms neem je bewust een lening voor snellere oplevering, maar soms bouw je die lening ook onbewust op.

Ik kan me gewoon niet zo vinden in de analogie, want ik heb in mijn leven nog nooit onbewust een lening op iets genomen. Dat is wat mij betreft niet hoe leningen werken.

Wat je in mijn ogen beschrijft is gewoon 'veranderende omstandigheden' en dat is dagelijkse kost voor iedere ontwikkelaar.

De requirements veranderen is gewoon een business cost. Een design kan nooit alle situaties aan. Een design is altijd op een bepaald principe gebaseerd, wat weer is gebaseerd op de requirements.

En als die requirements veranderen, dan kan het zijn dat ook het design niet meer van toepassing is. Dat is voor mij gewoon geen technical debt, maar gewoon verandering.

Begrijp me niet verkeerd, Technical Debt is een term die zeer weid verspreid is in de industrie, maar mede gevoed door de rant van een vriend van mij begrijp ik dat de term eigenlijk niet echt is wat het beweert te zijn in mijn ogen.

[Reactie gewijzigd door Q op 22 juli 2024 21:26]

[P_Tingen]

Ward Cunningham was kennelijk de eerste die de term gebruikte:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."[11]
— Ward Cunningham, 1992

Persoonlijk denk ik dat de kern van de definitie hierin zit:
Every minute spent on not-quite-right code counts as interest on that debt.

Die code kan not-quite-right zijn door verschillende oorzaken, zoals slecht geschreven, achterhaald of vanwege omgevingsfactoren zoals OS

[Sandor_Clegane]

Dat is wel een goede definitie, het punt is alleen dat je dus wel mensen moet hebben die weten wanneer ze "not quite right" code aan het schrijven zijn. Vandaar ook mijn opmerking over het leren herkennen.

Het lijkt een beetje een open deur: Weet je technical debt te herkennen, dan hoef je niet zo'n bord te hebben. Weet je het niet te herkennen dan maakt het niet uit, want je weet niet dat er een probleem is.

[Zwarte_os]

Precies. Ik denk dat er een mooie anekdote moet komen om technical debt uit te leggen. Korte case studies die laten zien hoe het niet investeren in je infrastructuur tot achteruitgang en vertraging leidt.

[mae-t.net]

Een mooie anecdote en, of dat zou aan mij liggen, een woord waardoor je in 1 keer weet waarover het gaat. Dat ligt niet aan de taal, technische schuld vind ik net zo vaag klinken als technical debt.

[Sandor_Clegane]

software pleister.

[wica]

Mijn uitleg van technical debt is als volgt.
Tijdelijke oplossingen uit het verleden, die permanent geworden zijn. Omdat het opgelost was en er geen tijd meer vrij gemaakt word om het goed op te lossen.

[DeeD2k2]

Ik vat jouw bericht op als "hoe kan je het achteraf zien?". In dat geval: dit zou helemaal geen vraag moeten zijn bij technical debt. Het maken van de schuld is een keuze die je maakt tijdens het ontwikkelen, eventueel al tijdens het ontwerp van het onderdeel dat je maakt (de refinement in SCRUM). Dan maakt je als ontwikkelaar of -team bewust de keuze om de oplossing niet zo te maken als je graag zou willen.

Dit valt of staat wel met vooraf afspraken maken over architectuur en je doelstellingen hebt voor bijvoorbeeld beheer en operations. Als je dat niet hebt gedaan, kan je ook niet bepalen of je afwijkt en zou je kunnen zeggen dat je nooit technical debt kunt hebben.

[Sandor_Clegane]

Je code kan ook door iemand anders worden bekeken. Het personeelsbestand wil nog wel eens wisselen.

[DeeD2k2]

I know. Maar als je dan aan de hand van code technical debt moet herkennen, heb je een registratieprobleem.

Ook dit heeft te maken met het maken en volgen van afspraken. Technical debt moet je altijd meteen vastleggen in je project management oplossing (scrumboard, voortgangsrapportage etc) zodat je het kan wegwerken gaan plannen.

Het is naïef om te denken dat het ook altijd gepland en weggewerkt gaat worden, maar het moet blij de beslissing transparant en bekend zijn voor de opdrachtgever/PO en later voor je opvolgers. Zodra oplossingen een puzzle worden, zal de TCO altijd blijven stijgen.

[Lick_A_Brick]

Kan zijn dat deze opmerking niet klopt, maar is een ander reden van Technical debt ook niet dat software leveranciers backwards compatibility willen behouden?

[418O2]

Dat kan zijn, maar dat kan je ook bereiken door het goed te abstraheren. En de keus maken hoe ver je wil gaan in backwards compatibility

[Gamebuster]

Wat ik niet snap: Als je merkt dat je 4 dagen tegen technical dept aanloopt, en het kost 2 dagen om te fixen... waarom fix je het gewoon niet zodra je het tegen komt?

[P_Tingen]

Omdat het meestal zo gaat: je loopt tegen iets aan wat 6 dagen ipv 4 dagen kost om het te maken. Die 2 dagen zijn je technical debt. Je zou het kunnen herschrijven maar dat kost je 5 dagen extra, dus 4 + 5. Als het een eenmalig iets is, heb je in dat geval 9 dagen besteed, wat ook in 6 had gekund als je de technical debt gewoon had laten zitten.

Het punt is dat je niet weet of je er in de toekomst nog weer tegenaan gaat lopen, anders was het inderdaad een makkelijke kwestie.

[Gamebuster]

Ja oke in praktijk gaat het meestal wel zo ja... je weet niet of je die ellende nog een keer aanraakt in de toekomst.

[Arrogant]

Te druk.

[SpiceWorm]

Heel leuk, zo'n artikel op tweakers en de discussie eronder! Met plezier en interesse gekezen!

[THA_ErAsEr]

Dit hebben we al meerdere keren in meerdere vormen geprobeerd op het werk en het eindigt altijd hetzelfde na enkele weken. De klant zegt dat er "dringendere" prioriteiten zijn en het project wordt vergeten.

Elk jaar komt dit dan terug nadat iemand bij de klant weer een openbaring heeft gehad door het bijwonen van één of andere lezing of na het bekijken van een youtube filmpje.

[Jewest]

lijkt wel op(zoals aangeveven door cappie onderaan de pagina):
http://fabiopereira.me/bl...nical-debt-retrospective/

plagiaat?