Repareren of opnieuw bouwen? Dit is hoe ik die keuze maak

Dit is een beslissing die ik dagelijks neem. Niet als grote strategische afweging met een vergadering erbij, maar gewoon, terwijl ik aan het werk ben. Er ligt iets dat aangepast moet worden, en de vraag is of ik het bestaande stuk ombouw of het opnieuw neerzet.

In verreweg de meeste gevallen wordt het een refactor. Dat klinkt misschien saai, maar het is de logische uitkomst van iets dat vanaf het begin goed in elkaar zit: als het fundament klopt, is aanpassen alles wat er nodig is. Je verplaatst een muur, je sloopt niet het huis.

Wanneer opnieuw bouwen wel de slimste zet is

Soms past een verandering simpelweg niet in wat er staat. Niet omdat de code slecht is, maar omdat hij gebouwd is rond een aanname die niet meer klopt. Dan kun je blijven duwen en trekken, met steeds meer uitzonderingen en omwegen, of je erkent dat dat specifieke onderdeel aan zijn eind is.

Let op het woord onderdeel. Opnieuw bouwen betekent bij mij bijna nooit de hele applicatie. Het betekent dat je één afgebakend stuk eruit haalt en opnieuw neerzet, terwijl de rest gewoon blijft draaien. Een volledige herbouw van een gegroeid systeem is een project waar je maanden in verdwijnt en waarbij je in de tussentijd geen enkele klant vooruithelpt.

Wat de doorslag geeft

De vraag is niet of iets te repareren is. Bijna alles is te repareren, als je maar genoeg tijd hebt. De vraag is wat goedkoper uitkomt.

Dus zet ik het naast elkaar. Wat kost het om dit uit elkaar te halen en netjes weer op te bouwen? En wat kost het om dit stuk vanaf nul te schrijven, inclusief alles wat er omheen zit en opnieuw getest moet worden? Valt de tweede som lager uit, dan bouw ik opnieuw. Valt hij hoger uit, dan blijf ik van de structuur af en pas ik aan wat er is.

Wat ik nadrukkelijk niet doe, is iets weggooien omdat het niet mooi is. Er staat in elk systeem code die niet het beste is wat ik heb gezien, en die zonder problemen zijn werk doet. Daar blijf ik vanaf. De bedrijfswaarde staat voorop, niet mijn gevoel voor nette code.

Hoe je die som maakt zonder ontwikkelaar te zijn

Je kunt die twee bedragen natuurlijk niet zelf uitrekenen. Wat je wel kunt doen, is de vragen stellen waar die som uit volgt.

Vraag hoeveel van het bestaande werk blijft staan bij een herbouw van dit onderdeel. Als het antwoord is dat alles eromheen hetzelfde blijft en alleen dit stuk vervangen wordt, is de schade te overzien. Vraag ook wat er stuk kan gaan aan de kant die je niet aanraakt. Een onderdeel dat overal vingers in heeft, is duurder te vervangen dan een onderdeel met één duidelijke aansluiting, ook al zijn ze even groot.

En vraag wat er gebeurt als je niets doet. Soms is dat een prima antwoord. Niet elk ongemak is een probleem dat je nu moet oplossen, en een lijst met irritaties is iets anders dan een lijst met kosten.

Een voorbeeld uit eigen huis

Bij Altrady liepen we vast op ons klantsupportsysteem. Het deed wat het moest doen, maar wij waren er niet blij mee, en dat gevoel bleef. Uiteindelijk hebben we het helemaal opnieuw gebouwd. Het werkt nu een stuk beter.

Wat ik interessant vind aan dat traject, is de tijdlijn. Van eerste idee tot opgeleverd duurde het ongeveer twee maanden. Het daadwerkelijke bouwwerk was ongeveer twee weken, en dat was er nog naast het gewone werk doorheen gedaan, als project ernaast.

Die anderhalve maand ertussen was geen wachttijd. Daarin zijn de ontwikkelaars zelf supporttickets gaan behandelen. Niet meekijken, niet een demo krijgen, maar echt zelf die tickets afhandelen. Zo kregen ze gevoel voor de flow, ontdekten ze waar het werkelijke probleem zat, en pas daarna hebben ze de oplossing ontworpen.

Zonder die maand tickets afhandelen hadden we in twee weken een nieuwe versie van hetzelfde probleem gebouwd.

Dat is het deel dat mensen overslaan. Opnieuw bouwen voelt als een technische beslissing, dus gaat de aandacht naar de techniek. Maar de reden dat de vorige versie tegenviel, was niet dat de code verkeerd was. Het was dat niemand precies wist waar het in de praktijk aan schuurde. Als je dat niet eerst uitzoekt, bouw je dezelfde mismatch opnieuw, alleen dan in nettere code.

Wat dit voor jou betekent

Als jij met een app zit die niet doet wat je wilt, is de eerste vraag niet of hij te redden is. De eerste vraag is waar het precies misgaat, en voor wie.

Soms blijkt dat één scherm te zijn waar iedereen op vastloopt, en dan ben je met een gerichte aanpassing klaar. Soms blijkt dat het ding gebouwd is voor een proces dat je inmiddels anders doet, en dan helpt geen enkele reparatie meer. Dat verschil zie je pas als je in de code kijkt en tegelijk in de praktijk kijkt. Allebei, niet één van de twee.

En als de uitkomst is dat een deel opnieuw moet, is dat geen ramp. Het is een afgebakend stuk werk met een prijs en een eindpunt. Mijn ervaring is dat het vaak kleiner is dan mensen vrezen, zolang je maar weet wat je bouwt voordat je begint.

Loop je hier tegenaan? Stuur me een bericht, dan kijken we waar jouw app precies staat en wat de goedkoopste weg vooruit is.