zaterdag 8 januari 2011

Technologie Schuld

Laatst kwam ik voor het eerst de term Technology Debt tegen; Technologie schuld (TS).

Stel je moet een aanpassing maken in de code van een applicatie. Om deze wijziging netjes te maken moeten er ook tabellen gewijzigd worden en wat andere zaken zoals een goede documentatie hierover. Door het echter kort door de bocht ofwel “quick and dirty” te doen door bijvoorbeeld niet een hulptabel te gebruiken maar een aantal waarden hard gecodeerd te doen en documentatie achterwege te laten creëer je een technologie schuld. De gedachte hierachter is dat je vroeg of laat de code opnieuw moet schrijven, wel netjes moet maken omdat je tegen beperkingen aan bent gekomen of dat de applicatie flexibiliteit mist waardoor bepaalde klanten niet meer met de software kunnen of willen werken. Door dus snel iets af te maken moet je later alsnog betalen (en wellicht meer en extra) om het snelle werk te herstellen en duurzamer te maken.

Het concept sprak me erg aan en ik heb er nu wel het één en ander van gelezen. Daar zag ik in mijn ogen foute voorbeelden zoals het niet invullen van requirements is niet per se een TS. Of dat het gehele concept anders werd uitgelegd of begrepen.

Ik heb in het verleden veel met TS te maken gehad, toen had ik er geen naam voor, nu wel. De analogie tussen een TS en een financiële schuld houdt een bepaald moment op, toch zit er waarde in de term en ik zal die toelichten.

TS bestaat en zit verweven in het vak en is bijna altijd een slecht zichtbaar risico. Ik kan het weten, want ik heb mij hieraan ook regelmatig schuldig gemaakt.

Nadat software is opgeleverd en ermee gewerkt wordt komen er wensen bij. Wensen worden beoordeeld en als deze uitgevoerd moeten worden komt dit bij de ontwikkelaars terecht. Vaak moet er ook nog een inschatting of een fixed price afgegeven worden en dan wordt de ontwikkeling uitgevoerd. Ik praat nu over een leverancier opdrachtgever verhouding, maar dit kan ook binnen een bedrijf zelf plaatsvinden, het gaat om de gedachte.

Het gebeurt regelmatig dat opdrachtgevers schrikken van de kosten voor een bepaalde verandering en ontwikkelaars of leveranciers willen de klant graag tegemoet komen. Ontwikkeling is vaak een schatting, dus er is ook nog wat ruimte, maar regelmatig wordt er ook een optie geboden. Bijvoorbeeld dat de ontwikkeling in minder uren en doorlooptijd kan, maar dat de invulling van de wens daardoor wel beperkter of minder flexibel is met oog op de toekomst. Hier wordt dus in feite een voorstel gedaan om een technologie schuld te creëren, en daar kan dus ook consensus over bestaan.

Ontwikkelaars zijn duur en dit komt mede omdat niet-ontwikkelaars niet goed snappen hoe ontwikkeling technisch werkt en vaak ook niet willen weten hoe iets technisch werkt. Daardoor is er vaak ook slecht zicht op of een ontwikkelaar goed is of niet.

Technologie schuld is niet per se slecht zolang er maar open over gecommuniceerd wordt. De schuld hoeft namelijk niet altijd ingelost worden. Iets kan kort door de bocht opgelost worden omdat het om een verandering gaat die slechts tijdelijk is, of functionaliteit door slechts door een klant of gebruiker gewenst is. In zo’n geval is kort door de bocht helemaal niet slecht. Pas als er verder op gebouwd moet worden ontstaat er meer schuld of wordt de schuld ingelost.

Ook bij een Proof Of Concept (POC) is de kans op TS groot. Nadat de POC goed is afgerond wordt er meestal niet opnieuw begonnen terwijl een POC juist kort door de bocht is opgesteld; namelijk om een punt te bewijzen.

Wat is het gevaar van een technologie schuld?
Zoals gezegd hoeft een TS geen probleem te zijn, zolang alle betrokkenen hiervan weten en er rekening gehouden wordt met de impact die het heeft of kan hebben.

Omdat een TS vaak niet berekend wordt en steeds groter kan worden door voort te bouwen op eerdere schulden kan de schuld enorm oplopen tot epische proporties. Dit hoeft overigens niet alleen maar te ontstaan door kort door de bocht oplossingen, maar door fouten in de uitgangspunten en/of architectuur. Stel dat een rechtenmodel van een eHRM oplossing erg rigide is opgezet en een wet veranderd of de organisatie veranderd van structuur, dan kan het zijn dat de software in zijn geheel niet meer aansluit op de organisatie of de klanten. Dit is geen TS, maar een tekortkoming in de architectuur van de software.

Om dit artikel abstract en dus kort te houden zal ik hier niet dieper op in gaan.

Het gevaar van TS is dat het vrijwel onzichtbaar is en mede omdat alleen ontwikkelaars de schuld kunnen zien is het een sluimerend gevaar. Want er is geen directe fout gemaakt. De software kan perfect volgens de specificatie functioneren, maar pas als er een wijziging nodig is komt het naar boven dat er onder de motorkap te kort door de bocht is gegaan, of dat een fundament ontbreekt.

In bepaalde gevallen kan er ook een TS ontstaan doordat door de quick en dirty oplossing er een veiligheidslek is ontstaan. Een voorbeeld hiervan is SQL injection, dus dat een kwaadwillende gebruiker een truuk toepast om de onderliggende database te manipuleren. Als er zonder schuld geprogrammeerd was (en de overige code wel goed gebouwd is), dan zou deze onveiligheid er ook niet inzitten. En nogmaals, een veiligheidslek of schuld kan heel lang verborgen blijven of zelfs nooit aan het licht komen.

Hoe wordt een TS voorkomen?
Omdat er doorgaans een kloof bestaat tussen ontwikkelaars en programmeurs en de rest van de wereld is voorkomen niet altijd gemakkelijk. Zeker niet omdat budget altijd beperkt is en er altijd druk van een deadline bestaat.

Iemand die genoeg weet van de ontwikkeltaal en software ontwikkeling algemeen, maar die ook de business en de behoefte begrijpt kan al een hoop schuld voorkomen. Je hebt dus een brug nodig tussen techniek en de business. Een ander hulpmiddel is een goede conventiebeschrijving. Dus aan welke regels en afspraken code moet voldoen. Daarnaast is een second opinion ook een goed idee. Iemand die niet extern van het project is en wel zelf kan ontwikkelen.

Omdat er geen breed gedragen codeer standaarden zijn is ontwikkelen toch nog wel een wilde westen. Geef twee groepen ontwikkelaars dezelfde opdracht en de oplossing kan volstrekt op een andere manier worden opgebouwd. Dit komt natuurlijk omdat programmeren virtueel is. Van zand kun je geen kantoor maken, van code kun je niet zien of deze stabiel en duurzaam is.

Het komt er dus op neer dat de ontwikkelaar(s) niet de enige zijn die naar de code kijken. Tijdens de initiële ontwikkeling is er vaak een actief team. Nadat software in productie is genomen kan het strak volgen van wijzigingen nog wel eens vergeten worden. Ook staan verantwoordelijkheden niet meer bij iedereen scherp op het netvlies en is de kans op TS dus groter.

Meer weten?
Over dit onderwerp en vooral de details kunnen boeken gevuld worden. Heeft u een verzoek? Wilt u meer weten? Toch voorbeelden of loopt u tegen een “schuld” aan? Neem dan contact op, ik help u graag.

Henri Koppen
Januari 2011


Links:
http://goo.gl/JyHFP  bij dit artikel las ik de term voor het eerst.