Kort-door-de-bocht of elegant?

Januari 2010 - Elke ontwikkelaar staat vroeg of laat een keer voor de keus om een nieuwe feature kort door de bocht of elegant te implementeren. De elegante manier zorgt ervoor dat de code ook in de toekomst overzichtelijk en onderhoudbaar blijft. De kort-door-de-bocht manier geeft snel resultaat, maar je weet tegelijkertijd dat deze oplossing ooit een keer pijn gaat doen verderop in het project (of tijdens de onderhoudsfase).

In de praktijk is het erg lastig om deze toekomstige pijn te kwantificeren, waardoor men al snel geneigd is om het probleem te bagatelliseren.

In dit Whitebook zal ik een aanpak introduceren waarmee je de discussie over deze pijn kunt voeren, ook (of juist) met opdrachtgevers en klanten. Samen is het dan gemakkelijker om te bepalen wat de juiste aanpak is: kort door de bocht, of elegant.

Technische schuld

Technische schuld is een term die in eerste instantie door Ward Cunningham geïntroduceerd is (Engels: technical debt). Het is een metafoor, die kort-door-de-bocht oplossingen vergelijkt met geldleningen. Geld leen je bij de bank en je betaalt er rente over. Een kort-door-de-bocht oplossing "leen" je van je broncode en je betaalt er ook rente over. Niet in de vorm van financiële rentebetalingen, maar als stukje van je ontwikkelsnelheid (velocity, of aantal storypoints per iteratie).

Technische schuld gaat vaak, maar niet altijd over broncode. Ook een kapotte buildserver (je hebt toch wel een buildserver?), of omslachtige handmatige release-procedures zijn op te vatten als technische schuld die impact hebben op de ontwikkelsnelheid van het team.

Als al deze rentebetalingen op meerdere stukjes technische schuld cumuleren, dan kan dat serieuze impact hebben op de velocity van het team.

Scrum

Scrum begint langzamerhand mainstream te worden. In steeds meer organisaties wordt bekeken of het zinvol is om over te stappen naar een meer agile proces van softwareontwikkeling. De belofte van Scrum is niet mis: hyperproductieve teams en altijd werkende software waar je écht wat aan hebt.

Eén van de pijlers van Scrum is dat de technische kwaliteit van de software hoog is en niet ter discussie staat. Als de technische kwaliteit laag is, kom je regelmatig voor onaangename verrassingen te staan. Als je elke keer tijd moet besteden om deze ongewenste bij-effecten van wijzigingen te bestrijden, blijft de belofte van hyperproductiviteit een fata morgana.

Technische schuld ondermijnt de technische kwaliteit van de software. Het is dan ook geen wonder dat Scrum-teams streven om zo min mogelijk technische schuld op zich te nemen. Veel teams maken dit expliciet door in hun "Definition of Done" op te nemen dat de technische schuld niet mag toenemen, of zelfs kleiner moet worden.

Teams die de hoeveelheid technische schuld actief managen en zo laag mogelijk houden, krijgen daar een fikse dosis flexibiliteit voor terug. Als de situatie er namelijk om vraagt, kunnen zij incidenteel, met betrekkelijk weinig consequenties, een relatief grote hoeveelheid technische schuld op zich nemen. Dit geeft een dergelijk team een groot voordeel ten opzichte van teams die continu "op het randje balanceren".

Het dilemma

Er komt een moment dat je opdrachtgever om een belangrijke feature vraagt, die in korte tijd in productie moet staan. Echter, om het in die tijd te halen, is de elegante oplossing absoluut geen optie. Aan de andere kant, als de deadline gemist wordt, betekent dat een serieus omzetverlies voor het bedrijf.

Wat doe je? Ik hoop dat niemand lang na hoeft te denken - de kort-door-de-bocht oplossing natuurlijk.

Dit voorbeeld geeft aan dat de beslissing om technische schuld op je te nemen niet altijd een slechte is. Het is echter wel belangrijk om dat bewust te doen, met een duidelijk doel. Net zoals bedrijven geldleningen afsluiten om te investeren, kan het in sommige gevallen opportuun zijn om wat technische schuld te accepteren.

Als de beslissing genomen is om wat te lenen van je broncode, zet deze lening dan direct op de product backlog. Op die manier weet iedereen dat er technische schuld is, die terugbetaald moet worden. Ook voor de opdrachtgever is het in dat geval duidelijk dat, omdat er nu een snelle oplossing gekozen is, in de toekomst extra tijd geïnvesteerd moet worden om deze schuld terug te betalen.

Misschien gaat er dan nog steeds enige tijd overheen voordat dit item van de product backlog opgepakt wordt, maar het dwingt de opdrachtgever tot een bewuste keuze tussen meer nieuwe features of een hogere kwaliteit.

Legacy

Veel software bevat in de loop van de tijd (jaren?) al veel technische schuld. Beginnen met Scrum is in dat geval geen gemakkelijke opgave: vrijwel elke wijziging doet pijn, en het blijkt dat zelfs voor schijnbaar triviale wijzigingen alle ontwikkelcapaciteit benodigd is. Er is dan al zoveel technische schuld dat het team alleen maar bezig is met rente betalen.

Technische schuld-curve

In zo'n geval is het verleidelijk om te hopen dat je software snel uit productie genomen wordt (is meestal een illusie) of dat je een jaar de tijd krijgt om het helemaal over te doen (dat is meestal een nog grotere illusie).

Een goede aanpak is om deze schuld stukje bij beetje terug te betalen (schuldsanering). Lever elke iteratie minimaal een nieuw stukje waardevolle software op, maar pak tegelijkertijd ook een stukje schuld op. Zorg er in ieder geval voor dat je geen nieuwe technische schuld introduceert (de eerste knik in bovenstaande curve). Hierdoor krijgt het team een meer constant ritme in opleveringen en de hoeveelheid opgeleverde functionaliteit. In een later stadium kan de hoeveelheid schuld actief teruggebracht worden (de tweede knik in bovenstaande curve).

Conclusie

Technische schuld is een bruikbare metafoor om juist met niet-technische stakeholders de consequenties van bepaalde keuzes inzichtelijk te maken. Met dit inzicht kun je samen de afweging maken welke keuze verantwoord is. Soms betekent dat dat je een bepaalde hoeveelheid schuld accepteert, in andere gevallen zal blijken dat de elegante oplossing de voorkeur heeft.

In een omgeving waarin al veel technische schuld bestaat, zorg dan eerst dat deze schuld niet meer toeneemt. Dit creëert een constant ontwikkeltempo. Na verloop van tijd loont het de moeite om te kijken welke schulden afgelost kunnen worden.

Referenties

• http://www.martinfowler.com/bliki/TechnicalDebt.html
• http://drdansplace.com/category/technical-debt/
• http://jrothman.com/blog/mpd/2009/10/expressing-technical-debt-as-user-stories-helps-with-roi.html
• http://jrothman.com/blog/mpd/2009/11/management-debt-technical-debt-and-decision-making.html
• http://www.crisp.se/henrik.kniberg/presentations/agile2008/Technical-Debt-how-not-to-ignore-it.pdf