Steeds meer ontwikkelaars gebruiken de iteratieve en incrementele software-ontwikkelmethode Agile. Deze methode biedt de mogelijkheid om vanaf het begin van het ontwikkelproces te sturen op (tussen)resultaten door deze herhaaldelijk af te stemmen met de klant. Maar hoe verhoudt Agile zich eigenlijk tot Technology Debt?
Technology Debt is het fenomeen dat zogenaamde short-cuts in broncode van software vaak in eerste instantie (tijds)winst lijken op te leveren, maar later problemen kunnen veroorzaken waardoor de 'schuld' inclusief 'rente' alsnog ingelost dient te worden. Interessant is de vraag of het voorkomen van Technology Debt op gespannen voet staat met iteratieve en incrementele software-ontwikkelmethoden zoals Agile. Zulke ontwikkelmethoden lijken het nemen van short-cuts namelijk te stimuleren.
Technology Debt
Alvorens verder in te gaan op de vraag of Agile software-ontwikkeling de kans op Technology Debt vergroot door short-cuts te stimuleren, eerst wat meer over Technology Debt. Iedereen kent de uitspraak ‘er zijn vele wegen die naar Rome leiden'. Zo is het ook met softwar- ontwikkeling; het realiseren van een specifieke oplossing kan op vele manieren. Uit eigen ervaring weet ik dat ontwikkelaars wel eens de weg van de minste weerstand kiezen. Bijvoorbeeld om een deadline te halen, of als gevolg van het ontbreken van ervaring. Op het eerste gezicht lijkt er vaak niets aan de hand omdat de software functioneel gezien gewoon werkt, maar er liggen risico's op de loer. Vanuit een technisch perspectief is er meestal sprake van imperfecties en/of omissies. Deze technische zwakheden worden short-cuts genoemd en kunnen serieuze problemen veroorzaken.
Ter illustratie een vereenvoudigd voorbeeld om het fenomeen Technology Debt uit te leggen. Op verzoek van een klant voegt een ontwikkelaar nieuwe functionaliteiten toe aan bestaande open source software. Om de deadline te halen voorziet de ontwikkelaar de wijzigingen in de broncode niet van commentaar (bedoeld om de werking van de broncode toe te lichten). De ontwikkelaar realiseert hiermee een besparing van vier uur, maar creëert tegelijkertijd een 'schuld'. Een jaar later vraagt dezelfde klant wederom om uitbreiding van de functionaliteit. Het maken van deze aanpassingen is echter lastig; de ontwikkelaar is inmiddels alweer met een ander project bezig en moet zich opnieuw inleven in dit 'oude' project. Omdat grote delen van de broncode niet zijn voorzien van commentaar, kost het de ontwikkelaar geen acht maar veertien uur om de nodige aanpassingen in de broncode door te voeren. De ontwikkelaar dacht dus vier uur tijd te besparen door bewust een 'schuld' te creëren (het niet gebruiken van commentaar), maar moest hier later zes uur voor terugbetalen (de 'schuld' inclusief de 'rente').
Dit voorbeeld maakt duidelijk dat de 'rente' van tevoren vaak onbekend is. Sterker nog, op het moment dat de ontwikkelaar ervoor koos om de broncode niet van commentaar te voorzien, was hij zich waarschijnlijk niet eens bewust dat hij een 'schuld' creëerde. Het optreden van Technology Debt en de eventuele hoogte van de uiteindelijke 'schuld inclusief rente' is dus lastig te voorspellen. Bovendien is Technology Debt moeilijk meetbaar en/of detecteerbaar. De short-cuts hebben veelal betrekking op niet-functionele aspecten van de broncode zoals bijvoorbeeld de onderhoudbaarheid, beveiliging, en aanpasbaarheid. Het niet opnemen van een specifieke functionaliteit is geen Technology Debt, omdat dit (hopelijk) een bewuste keuze is. Technology Debt heeft een meer verborgen karakter. Dus ook wanneer de functionaliteit in orde is en de applicatie voldoet aan de eisen van de klant, kan er nog steeds sprake zijn van Technology Debt.
Technology Debt is echter anders dan de klassieke financiële schuld. Het kan namelijk gebeuren dat een 'schuld' om wat voor reden dan ook niet terugbetaald hoeft te worden. Bijvoorbeeld omdat de klant nooit meer om wijzigingen vraagt, het project vroegtijdig wordt geannuleerd, of misschien wel omdat een ontwikkelaar denkt dat de ‘schuld' doorschuift naar zijn opvolger. En dat is nu juist de factor die Technology Debt aantrekkelijk maakt; een ontwikkelaar weet nooit zeker of short-cuts in de toekomst problemen zullen geven, waardoor er altijd een kans bestaat dat een 'schuld' niet terugbetaald hoeft te worden.
Agile
Agile software-ontwikkeling gaat uit van multidisciplinaire teams en korte ontwikkelcycli (weken) met na elke cyclus een testbaar resultaat voor de klant. Feedback en een eventueel veranderde doelstelling worden gebruikt om de prioriteiten voor de volgende ontwikkelcyclus vast te leggen. Op deze manier ontstaat op een snelle manier bruikbare en met de klant afgestemde software. Vaak worden Agile en soortgelijke methoden gezien als tegenhangers van de alom bekende watervalmethode waarin vooraf vastgelegde (proces) stappen in een strikt geplande volgorde worden doorlopen. Dit werkt vaak alleen wanneer de eisen aan het begin van het ontwikkeltraject helder zijn en niet meer veranderen. Tegenwoordig is dit steeds minder het geval. Klanten hebben steeds meer behoefte aan flexibiliteit waardoor ontwikkelaars in toenemende mate iteratieve en incrementele software ontwikkelmethoden zoals Agile gebruiken.
Het is echter de vraag of de ontwikkelmethode Agile de kans op Technology Debt groter maakt. Zoals het een goede methodiek betaamt, zegt Agile niks over het ontwikkelen als zodanig. Agile zegt alleen iets over het ontwikkelproces, zoals bijvoorbeeld de interactie tussen betrokkenen. Eén van de twaalf principes van de Agile ontwikkelmethode (zie kader) beschrijft zelfs dat er voortdurende aandacht voor hoge technische kwaliteit en een goed ontwerp dient te zijn. En dan komt het antwoord op de vraag in zicht. Technische uitmuntendheid en een goed ontwerp, of in dit geval correct omgaan met Technology Debt, is mensenwerk. Het enige wat een methode hieraan kan bijdragen is zorgen voor expliciete aandacht gedurende het ontwikkelproces. Daarom is mijn antwoord op de eerder geformuleerde vraag of Agile software ontwikkeling de kans op Technology Debt vergroot door short-cuts te stimuleren ‘Nee', Agile ontwikkeling stimuleert het nemen van short-cuts niet, maar biedt juist mogelijkheden om de kans op Technology Debt te verkleinen door hier expliciet aandacht voor te hebben.
Dat betekent echter niet dat hiermee alle gevaar is geweken. Het gebruiken van Agile is namelijk niet automatisch een garantie voor succes. De effectiviteit van de methode staat of valt namelijk met de wijze waarop ontwikkelaars hier invulling aan geven; een ontwikkelaar dient de Agile-mindset goed tussen de oren te hebben. Als een ontwikkelaar het gevoel heeft dat Agile snelheid prefereert boven kwaliteit, dan heeft deze de principes van Agile niet goed begrepen en gaat het mis. Dat is namelijk niet wat Agile beoogt. Agile zorgt ervoor dat de doorlopen paden niet teveel zijn afgeweken van de (veranderende) beoogde paden. Hierdoor ligt het eindresultaat veel dichter bij de wensen en eisen van de klant. En het heeft tevens tot gevolg dat er een stuk minder vertragingen zijn, wat uiteindelijk resulteert in een korte(re) doorlooptijd. Het verminderen van potentiële vertragingen vind ik echter iets anders dan het versnellen van klassieke software-ontwikkeling (bijvoorbeeld op basis van de watervalmethode) door het project in stukken te hakken en de druk bij de ontwikkelaar op te voeren.
Begrijpen, toepassen en samenwerken
Een veel voorkomend punt van kritiek met betrekking tot Agile is het feit dat deze methodiek alleen werkt bij ervaren software-ontwikkelaars. Vanuit het perspectief van Technology Debt kan ik het met deze kritiek wel eens zijn. Zoals gezegd is het omgaan met Technology Debt mensenwerk, en dan kan ik me prima voorstellen dat een ervaren ontwikkelaar zich eerder bewust is van het nemen van short-cuts, en de implicaties ervan op korte en lange termijn beter kan inschatten. Toch kunnen ook de minder ervaren ontwikkelaars correct omgaan met Technology Debt.
In eerste instantie is het belangrijk dat ontwikkelaars het fenomeen Technology Debt goed begrijpen; bewustzijn is namelijk de eerste stap om mogelijk ongewenste short-cuts te herkennen. Daarnaast is het belangrijk dat Agile op de juiste wijze wordt toegepast, door zoveel als mogelijk vast te houden aan de geformuleerde principes. Zorg er in ieder geval voor dat er ruimte is om zaken als Technology Debt met collega ontwikkelaars, en in sommige gevallen misschien wel met de klant te bespreken. De klant heeft namelijk de meeste kennis van zijn onderneming en kan waarschijnlijk het beste inschatten hoe groot de kans is dat door veranderende omstandigheden zijn eisen zullen veranderen, waardoor aanpassingen in de software noodzakelijk zijn.
Dennis Baaten, consultant Verdonck, Klooster & Associates
Principes Agile software ontwikkeling
- 1. Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.
- 2. Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.
- 3. Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.
- 4. Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.
- 5. Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.
- 6. De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.
- 7. Werkende software is de belangrijkste maat voor voortgang.
- 8. Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.
- 9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.
- 10. Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.
- 11. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.
- 12. Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.
(bron: http://agilemanifesto.org/)
Interessant.
Ik lees : “Een veel voorkomend punt van kritiek met betrekking tot Agile is het feit dat deze methodiek alleen werkt bij ervaren software-ontwikkelaars”
Er staat het feit maar dit raakt nog niet aan de eigenlijke oorzaak welke hier toevallig wordt opgevangen door ervaren ontwikkelaars. En dat is dat Agile een voortvloeisel is uit bepaalde kernwaarden aan welke een organisatie zichzelf wenst te meten.
De kernwaarde welke ten grondslag ligt aan het voorkomen van technical debt is “Getting things right the first time”. Om aan deze kernwaarde te voldoen MOET je technical debt voorkomen. Dit princiepe is breder toepasbaar, bijvoorbeeld op procedures, opmaak van een factuur, hoe je een telefoongesprek voert.
Bedrijven die ik ken welke Agile succesvol implementeren hebben altijd een aantal sterke kernwaarden vanuit welke ze handelen en Agile is daar een voortvloeisel van.
Mooie analyse Dennis. En Martin, je hebt gelijk. Je kunt Agile alleen maar succesvol implementeren als het bij de kernwaarden van je bedrijf past.
Ik ken bijvoorbeeld een sterk bureaucratische organisatie waarbinnen de IT-afdeling “Agile” werken in wil voeren. Men krijgt het intern echt niet uitgelegd.
Een grote veroorzaker van Technology Debt is volgens mij dat te veel software-oplossingen als een pilot of proof of concept beginnen. Maar daarna krijgt het team meestal niet de ruimte om opnieuw te beginnen. Er moet verder worden gebouwd o.b.v. het eerste concept. Gaandeweg worden de functionaliteiten steeds duidelijker en er onstaat een lappendeken. De business wil vaak quick fixes en zo ontstaat slecht onderhoudbare code.
Als ontwikkelteam moet je dus staan voor kwaliteit en de gevolgen van snelle keuzes direct benoemen en inderdaad zo goed mogelijk documenteren. Alleen dit vereist al senioriteit, tenminste bij de teamleider/projectmanager.
Binnen Agile werken wordt ter bewaking van de kwaliteit gebruik gemaakt van diverse op “tests” gebaseerde ontwikkelmethodieken. Dat is namelijk een eerste basale vorm van documentatie, zelfreflectie en kwaliteitsbewaking. Ook jonge ontwikkelaars is dit vrij snel aan te leren en die hebben hier direct baat bij.
Maar ja, vaak is er aan het begin van een project helaas geen tijd (lees geld) voor “tests”. Dan wordt dit vaak als onnodig ervaren (zowel door de business als vele ontwikkelaars). En daar onstaat direct Debt waarvoor je later de tol gaat betalen.
Schitterend artikel.
@ Martin, Peter beiden een goede aanvulling.
Uit eigen ervaring spreek ik als ik zeg dat het doen laten ontstaan van Technology Debt bewust of onbewust ‘verleidelijk’ is, zeker als er met korte sprints wordt gewerkt; werkende software opleveren is essentieel, en het lijkt alsof deze agile kernwaarde een hogere ‘rangorde’ is dan het vermijden van Technology Debt.
Natuurlijk is dit niet zo, maar je moet als ontwikkelaar stevig in je schoenen staan wanneer op je op een demo iets meldt in de trant van “we hebben niets kunnen opleveren, want tijdens het bouwen merkten we dat we technology debt’ veroorzaakten. Het kost ons meer tijd om analyse uit te voeren.
In mijn rol als tester bekroop mij(helaas) in agile projecten regelmatig het gevoel dat er technology depts ontstonden, al was het maar omdat er niet of of niet op een gestructureerde wijze gedocumenteerd werd….
Prachtig artikel, zo lees ik ze graag!
Ik zit vaak ook in ontwikkeltrajecten. Mijn ervaring is dat er juist na de oplevering de kans op “debt” groot is. Tijdens de initiele ontwikkeling was iedereen scherp en gemotiveerd. Maar na een tijd is de uitdaging weg, of liggen er nieuwe deadlines op andere projecten en is het toezicht niet scherp meer.
Het is ook mijn. Inzicht dat de kwaliteit van het team belangrijker is dan de methoe. Met goede mensen komt het bijna altijd wel goed.
Bij goede toepassing van Agile kan Technical Debt worden voorkomen. Niet alleen doordat er voortdurende aandacht is voor hoge technische kwaliteit maar juist door frequent werkende software op te leveren welke direct naar productie kan. Liefst wekelijks. Het team is en blijft verantwoordelijk voor de opgeleverde software en zal bij het ontstaan van technical debt steeds minder voorgang kunnen boeken. Dit werkt enorm frustrerend en zal het team willen voorkomen.
Een goede software engineer zal geen short-cuts willen nemen. Hij of zij wil goede onderhoudbare software maken. Goede toepassing van Agile/Scrum geeft teams de ruimte om hun werk goed te doen. Ze bepalen zelf hun planning en nemen als teams de volle verantwoordelijkheid.
Goed artikel, sluit me aan bij de conclusie dat met Agile methoden als Scrum beter om te gaan is met Technical Dept dankzij de volgende principes:
– Zichtbaar maken van wat je doet en wat je maakt. Het is lastiger om technical dept te ‘verstoppen’ door de intensieve communicatie en regelmatige opleveringen. Zo snel mogelijk feedback krijgen van andere teamleden en van de eindgebruiker is een van de agile principes.
– Samenwerking met business, de klant, de eindgebruiker. Beslissingen worden niet door IT alleen gemaakt maar zo veel mogelijk in overleg met de opdrachtgever. Technische afwegingen kunnen gekoppeld worden aan business doelen.
– Kennisdeling in het ontwikkelteam. Dankzij gezamenlijke aanpak door pair programming, code review, etc kunnen junior teamleden leunen op de ervaring van de senioren.
– Ownership door het team. Team beslist zelf hoe de implementatie gedaan wordt, is daarmee zelf verantwoordelijk voor die keuzes en de gevolgen.
In de praktijk heb ik ontwikkelaars naar 2 kanten zien doorschieten. Software met veel teveel shortcuts, maar wat net zo vaak voorkomt is over engineering. Samenwerking en afstemming met business doelen is de manier om ontsporen te voorkomen.