Schuldenproblematiek bij softwareontwikkeling

Het vroegere Cibit gaat na een management buy-out nu door het leven als Inspearit. Zij profileren zich nog altijd als deskundigen als het gaat om beoordelen van softwareontwikkeling en softwarekwaliteit. Op 19 juni 2012 organiseerden zij een seminar over Technical Debt.

Amerikaanse onderzoekers hebben de term Technical Debt ingevoerd, om aan te geven, dat je bij de ontwikkeling van software gebreken kunt inbouwen, die je later gaan opbreken cq geld gaan kosten. De parallel met de schuldenproblematiek van landen vond ik zeer intrigerend.

De belangrijkste spreker was een vrouwelijke onderzoeker van het Software Engineering Institute van Carnegy Mellon University in Pittsburgh: Ipek Ozkaya. Zij werkt in de vakgroep Architecture Centered Engineering. Zij licht achtergronden van Technical Debt toe. De term is bedacht door Steve McConnell. Hij onderscheidt twee typen van deze schuld. De eerste is onbedoeld en wordt veroorzaakt doordat een systeem wordt opgeleverd met foute specs en met fouten in de programmatuur. Ozkaya gaat daar verder niet op in, want kwaliteitssystemen en testen vindt ze vanzelfsprekend. Om de analogie met 'schuld' uit te werken: Als je schulden maakt, moet je rente betalen. Als je een onvolkomen systeem invoert, zul je in de loop der tijd kosten maken voor allerlei correctief onderhoud. Deze kosten kun je zien als de rente, die je betaalt over de aangegane schuld.

Het tweede type schuld is interessant. Je kunt namelijk bewust een onvolkomen systeem invoeren. Bijvoorbeeld om je time-to-market te verkorten. Bewust neem je dan als consequentie, dat je na enige tijd het 'quick and dirty'-systeem overnieuw moet bouwen, of dat je fiks correctief onderhoud zult moeten plegen. Dit is dus een strategische keuze, die verantwoord is, als je door de kortere time-to-market extra inkomen genereert, dat ruimschoots de betaalde rente overtreft.

Harm Spoor van Inspearit introduceert een kwadrant met IT Alignment langs de verticale as en IT Effectiveness langs de horizontale as. Ik interpreteer IT Effectiveness daarbij als een goed geleide IT-organisatie die de operaties foutloos laat draaien en die storingen bliksemssnel signaleert en oplost. De klassieke uitdaging is weer om van linksonder (Maintenance Zone) te komen in het kwadrant rechsboven ( IT enabled growth). Ga je via linksboven (alignment trap) of via rechtsonder (well-oiled IT)? Het eerste pad wordt meestal gekozen vanwege martkdruk en de noodzaak tot snelle aanpassing. Maar hier loopt men risico om technical debt op te lopen. Iedereen kent wel de situatie, dat snel een pakket moet worden ingevoerd om een produkt te kunnen introduceren. Het tweede pad (eerst de IT geheel op orde brengen) is de koninklijke weg en die duurt natuurlijk weer te lang. Volgens Spoor wordt vaak een duale aanpak gekozen. Waarschijnlijk dan de quick-and-dirty route voor strategische innovaties en de meer solide route voor de ondersteunende, meer intern gerichte systemen.

Ipek Ozkaya waarschuwt, dat ook de koninklijke weg gevaren kent. Bijvoorbeeld het gevaar van over-architecting. Ik kan mij dat helemaal voorstellen. De intern gerichte mensen, die steeds maar hun plaatjes blijven verfijnen en niet de sense of urgency voelen voor wat er in de markt gebeurt.

Zij besluit met drie strategiën voor de aanpak van technical debt:

1. Do nothing. Things will get worse.

2. Replace. High cost and high risk.

3. Incremental refactoring. Commitment to invest.

Alle drie de opties (ook de eerste!) kunnen geboden zijn. De beslissing vereist een goed inzicht in de interne en externe situatie van het bedrijf.