Op de blog van de Software Engineering Institute van de Carnegie Mellon University schreven ze over hun onderzoek naar technical debt.
In de inleiding geven ze een mooie omschrijving:
In their haste to deliver software capabilities, developers sometimes engage in less-than-optimal coding practices. If not addressed, these shortcuts can ultimately yield unexpected rework costs that offset the benefits of rapid delivery. Technical debt conceptualizes the tradeoff between the short-term benefits of rapid delivery and long-term value.
Weloverwogen kiezen voor technische schuld om op korte termijn sneller resultaat te boeken kan slim zijn. Voorwaarden zijn dat je niet teveel rente betaalt (extra werk) en de lening aflost (netjes oplossen).
Maar wat ik treffend vind aan de omschrijving van de CMU is de eerste zinsnede: "in their haste ...".
Lang niet altijd is technische schuld het gevolg van een bewuste keuze waarbij de kosten en baten zijn afgewogen. Bijvoorbeeld door tijdsdruk, slordigheid, gebrek aan ervaring (onbewust onbekwaam) of een foute inschatting ("deze code zal nergens anders gebruikt worden").
En voor je het weet heb je een project met slechte architectuur, te complexe code, onvoldoende documentatie en te weinig tests (de top 4 uit de studie). En dan kan het al (praktisch) te laat zijn om het te fixen. Het is goedkoper om het opnieuw te maken.
Daarom is de volgende alinea cruciaal:
Managing technical debt is an increasingly critical aspect of producing cost-effective, timely, and high-quality software products, especially in projects that apply agile methods.
Om technische schuld te kunnen managen moet je eerst weten dat je het hebt. En hoe eerder je dat weet, hoe beter je het kunt managen.
Voor mezelf heb ik drie aanbevelingen eruit gehaald:
- We moeten ervoor zorgen dat alle ontwikkelaars zich bewust zijn van wanneer ze "less-than-optimal coding practices" hanteren.
- We moeten zorgen voor een manier om die plekken in de code te markeren zodat we op tijd kunnen refactoren.
- We moeten de technische schuld waar we het meeste last van hebben in kaart brengen en die actief oplossen.
Over dat laatste punt volgt binnenkort nog een vervolgblogje!