Als ondernemer heb je vast wel eens nagedacht over de staat van je software. Kost het toevoegen van features steeds meer tijd of reageert je app trager en trager? Als je te maken hebt met software die je zakelijke doelen in de weg staat, dan is het tijd om actie te ondernemen.
Je hebt dan een aantal opties: op dezelfde voet doorgaan, je bestaande softwareoplossing moderniseren of investeren in een volledige herbouw. Welk van die opties is de beste voor jou?
Een schone lei
Bij herbouwen schrijf je je software helemaal opnieuw. Alle code wordt opnieuw geschreven en data wordt gemigreerd naar de nieuwe omgeving. Je kunt je richten op het implementeren van de beste oplossing, zonder dat je last hebt van de mindere keuzes uit het verleden. Je verbetert de performance en beveiliging, en je maakt je software toekomstbestendig.
Herbouwen is een grote klus, maar je begint wel met een schone lei. Echter heeft herbouwen ook een aantal nadelen.
Dubbel werk
Kies je voor herbouw, dan zul je met dezelfde bezetting aan twee codebases tegelijk moeten werken: je nieuwe en je bestaande. Je huidige software blijft immers in gebruik en moet dus ook security- en bugfixes ontvangen. Nieuwe features moeten nu in twee applicaties worden geïmplementeerd. Dubbel werk dus.
Naast het extra werk van het onderhouden van twee applicaties krijgt je team nu ook te maken met context switching. Het wisselen van de ene naar de andere taak kost mentale inspanning en zorgt voor nog eens een extra negatieve invloed op de productiviteit van je team.
Verder is een veelgemaakte fout om de herbouw in één keer te doen: de big-bang aanpak. Je team werkt dan maandenlang aan de nieuwe software, en pas als deze klaar is, wordt deze in gebruik genomen. Dat zorgt gegarandeerd voor onvoorziene performanceproblemen, bugs en vergeten features, en dus meer werk en kosten.
Niet doen dus?
Is herbouwen dan per definitie een slecht idee? Dat niet per se, maar het is een minder rooskleurige route dan je misschien denkt.
Is de broncode van je software geschreven in programmeertalen of frameworks die niet meer worden ondersteund? Weet niemand meer hoe de code werkt? Bevindt je applicatie zich echt in een deplorabele staat? Dan is herbouwen misschien de enige valide optie, maar in alle andere gevallen is moderniseren, of refactoren, de moeite waard om te overwegen.
Kleine stappen
Bij refactoren verbeter je je bestaande software zonder dat je de functionaliteit verandert. Dit betekent dat je de code schoonmaakt, de structuur verbetert en de performance optimaliseert. Je maakt je software klaar voor de toekomst door het doorvoeren van de best practices van nu.
Je software voelt weer als een nieuw project. Het toevoegen van features verloopt weer vlot, beveiligingsrisico's zijn weggepoetst en je applicatie reageert weer snel en soepel op interacties van gebruikers. Bovendien is het makkelijker om ontwikkelaars te vinden (en enthousiast te krijgen) voor het doorontwikkelen van jouw software.
Een kenmerk van refactoring is dat je software altijd operationeel blijft. Elke verbetering wordt direct in gebruik genomen. Je hoeft dus niet te wachten tot de herbouw klaar is om de voordelen te ervaren. Deze kleine stappen zorgen er voor dat risico's en onvoorziene problemen snel worden ontdekt en opgelost.
Software als levend organisme
Het lijkt een gegeven dat software na verloop van tijd veroudert en vervangen moet worden. Dat hoeft niet zo te zijn.
Zie software als een tuin. De natuurlijke staat van een tuin, als je er niets aan doet, is dat hij verwildert. De planten groeien door elkaar, de paden raken overwoekerd en de tuin wordt een ondoordringbaar oerwoud. Het kost dan veel tijd en moeite om de tuin weer op orde te krijgen.
Om een tuin mooi en gezond te houden moet je hem regelmatig snoeien en verzorgen. Je tuin blijft bruikbaar door onkruid te verwijderen en de juiste planten de juiste hoeveelheid water, zonlicht en voedingsstoffen te geven.
Vertaald naar de wereld van softwareontwikkeling betekent dit dat je je focust op het voorkomen dat code langzaam aftakelt, door middel van refactoren en het verwijderen van ongebruikte code. Door je codebase continu te verzorgen, blijft je software in een goede en bruikbare conditie.
Een dagelijkse routine
Om software in een blijvend gezonde staat te houden, moeten ontwikkelaars daarom tijdens het toevoegen of veranderen van code altijd aandacht besteden aan de kwaliteit van de codebase. Dat betekent continu nadenken over de duurzaamste implementatie van de functionaliteit en het toepassen van de juiste design patterns. Af en toe betekent dat één stap terug doen om er daarna twee vooruit te kunnen zetten.
Door refactoren als integraal onderdeel van softwareontwikkeling te zien, kun je je software up-to-date houden en voorkom je dat je software uiteindelijk bij het grofvuil belandt.
Refactoren is een minder ingrijpende klus dan herbouwen. Je neemt kleine stappen waarbij de risico's te overzien zijn. Wel vereist het discipline om blijvend aandacht te besteden aan de beslissing om je code naar een acceptabel kwaliteitsniveau te brengen.
En daar ligt ook een taak voor jou als opdrachtgever. Als je moet kiezen tussen het toevoegen van een nieuwe feature of het verbeteren van de kwaliteit van de code, wat kies je dan? Het is verleidelijk om voor die nieuwe feature te kiezen, en de kwaliteit van code voor je uit te schuiven.
Doe je dat te vaak en te lang, dan zal de ontwikkeling van je software op de lange termijn steeds meer tijd gaan kosten.
Conclusie
Continu refactoren is een investering in de toekomst van je software die zichzelf terugbetaalt in de vorm van een snellere time-to-market, minder bugs en een betere performance.
Herbouwen daarentegen is een laatste redmiddel. Hoewel het aantrekkelijk klinkt om met een schone lei te beginnen, gaat deze keuze gepaard met hoge kosten en onzekerheid.
Soms is herbouwen onvermijdelijk. Echter, met de juiste zorg, aandacht en discipline zorg je ervoor dat je dat punt nooit bereikt.
