Veel bedrijven zijn afhankelijk van (mobiele) applicaties om hun product in de moderne economie aan te kunnen bieden. De huidige consument is veeleisend en applicaties worden daarom continu uitgebreid, verbeterd en geperfectioneerd. Vaak draaien applicaties al enkele jaren in productie en is er over deze tijd zoveel aan toegevoegd dat het eigenlijk niet meer past.

De stabiliteit neemt af - en wat ogenschijnlijk eenvoudige aanpassingen hadden moeten zijn, hebben een onvoorziene impact op het gebruiksgenot. Eindgebruikers beginnen hun vertrouwen te verliezen.

Daarnaast zijn er inmiddels veel nieuwe technologieën op de markt die de ontwikkelaars graag willen toepassen, maar lijkt dat binnen de huidige architectuur niet te passen.

Wat zijn dan als bedrijf de mogelijkheden? Blijf je bouwen op een steeds op een steeds instabielere applicatie waardoor betrouwbaarheid en gebruiksvriendelijkheid in het nauw komen? Of kies je voor een rewrite? Maar dan in één keer goed. Met een gedegen basis. Al dan niet met microservices. En geschikt voor de toekomst. “Geef ons een (half) jaar”.

Het is een bekend verhaal dat zelden goed afloopt. De ambities zijn te hoog, de complexiteit valt tegen en gebruikers worden ongeduldig.

WANNEER KIEZEN VOOR EEN REWRITE?

• Als de technologie niet meer wordt ondersteund door de leverancier is het tijd om een rewrite te overwegen. Het risico van bijvoorbeeld uitblijvende (beveiligings) updates kan overigens ook voor lief worden genomen door de impact (kans maal effect) in te schatten.

• De applicatie is klein genoeg en het team is ervaren genoeg om de klus binnen enkele weken te klaren.

WANNEER IS EEN REWRITE GEEN (GOEDE) OPTIE?

• Als de code verwaarloosd is en er een hoge ‘technical debt’ moet worden afbetaald zou je moeten afzien van een rewrite. Goede, onderhoudbare code schrijven is een vak apart en door een rewrite krijgt de code niet opeens deze eigenschappen.

• Het kan ook zijn dat de technologie uit de mode is geraakt of dat er wordt gesproken van ‘legacy’. Dat heeft al snel een negatieve lading, terwijl het eigenlijk betekent dat het bewezen en bruikbaar is. Heb je gedegen code die voor je werkt? Houden zo.

VOORDELEN VAN EEN REWRITE

Dat neemt niet weg dat er nieuwe inzichten en betere manieren van werken zijn die pas echt tot hun recht komen op een nieuw platform. Daarnaast is het vinden van developers die met moderne technologieën willen - en kunnen - werken een stuk makkelijker.

CO-EXISTENTIE

De sterkste strategie is een co-existentie van oude en nieuwe code. Gebruik zo snel mogelijk de functionaliteit van de rewrite, terwijl de oude versie ook nog wordt gebruikt. Dit introduceert wel veel complexiteit aan het begin van het traject, omdat beide systemen in de lucht worden gehouden en moeten beschikken over dezelfde gegevens. Het voordeel is dat de meest moeilijke en risicovolle stap; de migratie naar het nieuwe systeem, voortdurend wordt uitgevoerd, zodat er heel veel ervaring ontstaat. Practice makes perfect!

Ondertussen kunnen waardevolle functionaliteiten live gezet worden voor eindgebruikers en hun feedback worden verzameld voor het maken van vervolgkeuzes. Dit heeft als groot voordeel dat projecten sneller kunnen beginnen, omdat niet alle keuzes vooraf bepaald hoeven te worden. Daarnaast blijkt het vaak ook lastig om projecten vooraf goed te definiëren en is het moeilijk om afscheid te nemen van oude features of functionaliteiten. Zo wordt een rewrite project al snel gedefinieerd als: ‘alles wat het vorige systeem kon, plus alle extra dingen’. Zonder tussentijdse feedback van gebruikers, wordt er een applicatie gebouwd op basis van theorie en niet op praktische functionaliteit. Door het vragen om feedback, verhoog je bovendien de acceptatiegraad en steun voor het project.

Een andere valkuil die je kunt ontwijken door deze aanpak is het onderschatten van de opnieuw te bouwen functionaliteit. Zijn de originele ontwikkelaars nog aanwezig, zijn er nog genoeg domeinexperts die weten hoe de processen werken? En vergeet ook niet al het bloed, zweet en tranen die het over de jaren heeft gekost om alle bugs te vinden en op te lossen. Door voortdurend kleine functionaliteiten op te leveren kom je er al snel achter of de nieuwe oplossing volledig en de juiste is.

Tot slot kan deze aanpak nooit mislukken. Want na elke feedbackronde is er een product of feature die in principe af is. Zo wordt er om de week al direct waarde toegevoegd aan het eindproduct en is een sprint dus nooit voor niets. De applicatie wordt elke ronde beter en gebruiksvriendelijker totdat er uiteindelijk een volledig nieuw product staat. Het grote voordeel is dat gebruikers al direct meeprofiteren en er altijd een product komt waar gebruikers mee uit de voeten kunnen. Win-win!

FINAL TIPS

• Laat het oude en het nieuwe systeem in het begin meteen naast elkaar bestaan.
• Neem herschreven code meteen in gebruik.
• Migreer en verbeter functies naar belangrijkheid voor de gebruikers, niet het hele product.
• Technologie is je vriend. Gebruik database triggers en reverse proxies.
• Gebruikers tolereren meer dan je denkt, als je naar ze luistert.
• Meer weten over deze aanpak? Lees onder andere het Strangler pattern en Working Effectively With Legacy Code.