Meten, niet gokken
Draai een statische analyse over de hele codebase. Je wilt weten waar de problemen zitten, niet vermoeden dat ze er zijn.
Je MVP is gefinancierd. En nu?
De demo werkt, de eerste klanten betalen, er is geld opgehaald. En nu ligt er een codebase waarvan niemand precies weet hoe hij in elkaar zit. Dat is geen falen — het is de normale uitkomst van snel bouwen. De vraag is wat je ermee doet.
01/10
Wat er onder de motorkap zit
Niet slechte code, maar code zonder samenhang.
Metingen op AI-gegenereerde code laten steeds hetzelfde zien: ongeveer anderhalf tot twee keer zoveel grote problemen als in met de hand geschreven code, en aanzienlijk meer beveiligingsfouten. Nog veelzeggender is de verhouding tussen geplakte en herschreven code: sinds AI-gereedschap gewoon werd, groeit het geplakte deel harder.
Dat is precies wat je verwacht van gereedschap dat optimaliseert voor werkende code in plaats van voor onderhoudbare code. Elke losse oplossing klopt; het geheel heeft alleen geen vorm. Dezelfde logica staat op vier plekken, met vier kleine verschillen.
Zolang jij de enige bent die eraan werkt, merk je dat nauwelijks. Zodra er een tweede persoon bijkomt, of jij zelf na drie maanden terugkomt, wordt het de rem waar iedereen het over heeft.
02/10
Waaraan je het herkent voordat het pijn doet
Vier signalen die eerder komen dan de eerste storing.
Het eerste signaal is dat kleine wijzigingen lang duren. Een knop verplaatsen zou een uur moeten zijn; als het een dag is, komt dat doordat je niet weet wat er nog meer aan die knop hangt.
Het tweede is dat niemand durft te verwijderen. In een codebase met samenhang gooi je met een gerust hart iets weg. In een codebase zonder samenhang laat je alles staan, omdat je niet kunt overzien wie het gebruikt. Dat is de reden dat deze projecten alleen maar groeien.
Het derde is dat dezelfde fout meerdere keren terugkomt. Je repareert hem op de plek waar hij opduikt, en drie weken later is hij er weer op een andere plek — omdat dezelfde logica op vier plaatsen staat.
Het vierde is dat het testen met de hand gebeurt. Zolang de enige manier om te weten of het werkt een rondje klikken is, blijft elke wijziging een risico dat iemand persoonlijk moet dragen.
03/10
Wat je als eerste doet
De grenzen zoeken
Welke delen raken elkaar en welke staan los? Wat los staat, kun je later aanpakken. Wat overal doorheen loopt, eerst.
Tests op de kern
Niet overal, wel op het pad dat geld oplevert. Zonder die tests is elke herbouw een gok.
04/10
Wat je herbouwt en wat je laat staan
Wel zinvol
- Alles rond inloggen, rechten en betalen
- Code die drie of meer andere delen aanraakt
- Wat je niet in een uur kunt uitleggen aan iemand anders
Niet zinvol
- Schermen die werken en zelden veranderen
- Losse hulpfuncties zonder afhankelijkheden
- Code die lelijk is maar afgebakend en getest
05/10
De volgorde die werkt
Van buiten naar binnen, en nooit alles tegelijk.
Begin bij de randen waar geld of gegevens langsgaan: inloggen, rechten, betalen, gegevensopslag. Dat is waar een fout je klanten kost in plaats van je tijd. Die delen mogen saai en degelijk worden, ook als de rest dat nog niet is.
Werk daarna naar binnen, per gebied, met een werkende app na elke stap. De verleiding om alles in één keer op te trekken is groot en het is de manier waarop teams drie maanden stilvallen zonder dat er iets te laten zien is.
Laat de schermen voor het laatst. Die zien er vaak het slechtst uit onder de motorkap en ze doen het meestal prima. Ze zijn ook het makkelijkst te vervangen als je later toch een andere kant op wilt.
06/10
Wat je meet om te weten of het helpt
Zonder cijfers is opruimen een gevoel.
De bruikbaarste maat is hoe lang het duurt voordat een wijziging bij de klant is. Niet hoe lang het bouwen kost, maar de hele weg van idee tot live. Als die tijd na twee maanden opruimen niet korter is geworden, ruim je de verkeerde dingen op.
Een tweede maat: hoeveel van de wijzigingen die live gaan, moeten binnen een week worden hersteld. Dat cijfer zegt meer over de staat van je codebase dan welk kwaliteitsrapport ook, en je hoeft er niets voor te installeren.
Wat je bewust níet als maat neemt: het aantal opmerkingen in een analysehulpmiddel. Dat getal daalt door dingen op te lossen die niemand raakt, en het geeft een gevoel van vooruitgang dat niet met de werkelijkheid meebeweegt.
07/10
Wat dit met je team doet
- De eerste ontwikkelaar die erbij komt, is niet je snelheid maar je toets. Wat hij niet begrijpt, is niet zijn probleem maar jouw schuld.
- Reken op een periode waarin er minder nieuwe functies bij komen. Dat is geen vertraging maar de rekening van eerder.
- Documenteer terwijl je herbouwt, niet erna. Wat je nu weet en niet opschrijft, moet iemand over een half jaar terugvinden.
- Blijf ondertussen bouwen aan wat klanten willen. Een team dat een half jaar alleen opruimt, verliest het gevoel voor waarvoor het opruimt.
08/10
Waar het meestal duur wordt
Twee dingen kosten in deze fase het meest. Het eerste is de gegevensstructuur: als de tabellen niet passen bij wat het product inmiddels doet, sleep je die mismatch mee in alles wat je erbovenop bouwt. Dat is het enige onderdeel waarvan we zouden zeggen: doe het nu, hoe vervelend ook.
Het tweede is de plek waar je platform je vasthoudt. Een MVP die op één bouwplatform is gemaakt, draagt aannames van dat platform mee — over hoe je gegevens opslaat, hoe je gebruikers beheert, hoe je uitrolt. Zolang je daar blijft, is dat prima. Wil je eruit, dan blijkt hoeveel van je app eigenlijk van hen was.
Wat zelden de moeite waard is: een andere programmeertaal, een ander framework, een andere hostingpartij. Dat voelt als vooruitgang en het lost geen enkel probleem op dat je klanten merken.
09/10
Hoe je dit uitlegt aan een investeerder
Niet als schuld die moet worden afbetaald, maar als de prijs van de snelheid waarmee je het bewijs hebt geleverd. Zonder die snelle demo was er niets om in te investeren geweest.
Wat je wél wilt laten zien: dat je weet waar het zit. Een lijst met gebieden, wat er per gebied misgaat en wat het kost om het aan te pakken, is een beter gesprek dan een belofte dat het meevalt. Investeerders die vaker software hebben gezien, verwachten dat lijstje en worden nerveus als het er niet is.
10/10
Veelgestelde vragen
Hoeveel van de codebase moet er meestal opnieuw?
Er is geen vast percentage, en iedereen die er een noemt, gokt. Wat we in de praktijk zien: de randen rond gegevens en betalen bijna altijd, de schermen bijna nooit.
Kan ik gewoon doorbouwen en dit later doen?
Voor een deel wel. Wat niet kan wachten is de gegevensstructuur en alles rond rechten, omdat elke functie die je erbovenop zet de fout vermenigvuldigt.
Moet ik een ervaren ontwikkelaar aannemen of inhuren?
Voor deze fase is inhuren vaak sneller, omdat het werk een duidelijk einde heeft. Voor daarna wil je iemand die blijft; degene die opruimt kent de codebase daarna beter dan jij.
Wat als de oorspronkelijke bouwer weg is?
Dan begin je met lezen en meten in plaats van met bouwen. Reken op een paar weken waarin er niets zichtbaars gebeurt en er wel een beeld ontstaat.
Is een volledige herbouw ooit het juiste antwoord?
Zelden, en bijna nooit zo vroeg. Een herbouw duurt altijd langer dan gedacht en levert een product op dat precies doet wat het oude deed, terwijl je klanten ondertussen wachten.
Hoe voorkom ik dit bij de volgende versie?
Niet door langzamer te bouwen, maar door tijdens het bouwen bij te houden welke keuzes je bewust uitstelt. Een lijst van twintig regels is genoeg om later gericht terug te komen.
