Technische schuld

De software wereld zit vol met Engelse begrippen. “Technical Debt” is ook zo’n begrip. Maar wat is het?

Een dag geleden zag ik dit bericht waarin Technical Debt werd vergeleken met een continue slecht gestapeld Tetris spel. Een rake vergelijking: als je niet oppast wordt de technische structuur van een applicatie een stapeling op zichzelf oplosbare problemen, maar vormt het in z’n geheel een nagenoeg niet te redden constructie.

Maar waar hebben we het dan over?

Technische schuld wijkt af van financiële schuld. Om financiële schuld te maken moet je geld lenen van een ander. Technische schuld ontstaat doordat er geen tijd wordt gestoken in het goed op orde maken van de techniek. Zo is het een goede gewoonte om kritische zaken en/of zaken die erg foutgevoelig zijn in de applicatie te voorzien van automatische tests (“kan die rol wel/niet bij die gegevens?”, “gaat het ook goed als hier een negatief getal in wordt gevoerd?”). Dit is extra techniek die fungeert als stutwerk: iedereen maakt wel eens een fout, maar als er iets goed fout gaat dan kunnen de extra regels testcode helpen die fouten op te sporen alvorens de code wordt gebruikt door mensen.

Pas op! Technische schuld maken kost geld.

Technische schuld lijkt dan wel weer op financiële schuld wanneer het gaat om de kosten: op den duur kost het geld. Een applicatie met veel technische schuld moet continue worden getest door mensen. Veelal krijgen ontwikkelaars op een gegeven moment ook de angst dat ze een applicatie ook niet meer durven aan te passen, omdat ze niet meer begrijpen wat er gebeurd en of dat ze niet goed kunnen doorzien of ze iets kapot zouden maken als ze iets aanpassen. Dit heeft als gevolg dat het ontwikkelproces erg traag gaat. En tijd is nog steeds geld.

Voorkom fouten

In bijna alle applicaties waaraan ik heb meegewerkt / die ik heb gebouwd zit wel enige mate van technische schuld. Ik ben niet roomser dan de paus. Kleine projecten worden soms volledig zonder tests opgeleverd, iets dat best kan als de applicatie in een paar kliks/swipes te doorzien is. Helaas gaat zo’n inschatting ook wel eens mis en is een applicatie stiekem alweer complexer geworden dan gedacht, met als gevolg dat ook ik wel eens zaken oplever die niet werken zoals ze zouden moeten werken. Dit is vaak zeer irritant voor de eindgebruiker, maar ook voor mijzelf als maker, want fouten oplossen en opsporen beschouw ik het eerste half jaar na oplevering als iets voor mijn eigen rekening. Het kost veel meer energie om naderhand een fout op te sporen dan een fout voorkomen.

Een beetje technische schuld mag best

Maar technische schuld kan, net zoals financiële schuld, tot op een bepaald niveau aanvaardbaar zijn. Soms is experiment zonder extra bescherming gewenst om snel iets uit te proberen en/of te veranderen, iets dat lastiger met veel code die continue test of alles nog wel werkt volgens de verwachting. Vandaar dat die Tetris vergelijking ook zo treffend was, want op een gegeven moment kun je daar niet meer mee door gaan.

Behoefte gekregen aan (een) pragmatische ontwikkelaar(s) die gericht is/zijn op de eindgebruikerservaring? Neem eens contact op met murb!