Heilige huisjes omver gooien: wanneer je codebase baat heeft bij een beetje anarchie

Er hangt een ongeschreven wet in veel dev-teams: volg de best practices, houd je aan de conventions, en twijfel nooit hardop aan wat Stack Overflow zegt. Begrijpelijk. Structuur brengt rust, en rust brengt productiviteit. Maar soms is het precies die keurige gehoorzaamheid die innovatie in de weg staat.

Bij PiratePad geloven we niet in regels om de regels. We geloven in bewuste keuzes — inclusief de keuze om een gevestigde aanpak overboord te gooien als die je meer kost dan oplevert. Dit artikel is voor de developers en teams die durven te vragen: waarom eigenlijk?

De mythe van de 'universele best practice'

Best practices zijn geen natuurwetten. Ze zijn oplossingen die ooit, in een bepaalde context, voor bepaalde mensen heel goed werkten. REST was een antwoord op een specifiek probleem. MVC ook. Microservices eveneens. Maar ergens onderweg zijn ze van aanpak naar dogma geëvolueerd.

Neem het Nederlandse fintech-bedrijf dat een paar jaar geleden bewust koos om geen microservices-architectuur te bouwen, op een moment dat iedereen daar massaal naartoe migreerde. Hun redenering? Een klein team van zeven developers had simpelweg niet de operationele capaciteit om tientallen services te beheren. Ze kozen voor een goed gestructureerde monoliet — en leverden daarmee sneller, met minder bugs, dan concurrenten die blind de hype volgden.

Dat is geen luiheid. Dat is scherpzinnigheid.

Drie tekenen dat jouw team toe is aan wat constructieve anarchie

Niet elk team is klaar om conventies los te laten. Maar er zijn signalen die erop wijzen dat je huidige aanpak je meer beperkt dan ondersteunt:

1. Je lost hetzelfde soort problemen steeds opnieuw op Als je merkt dat je dezelfde workarounds bouwt, sprint na sprint, dan is dat een teken dat de onderliggende structuur niet klopt. De conventie werkt misschien niet voor jouw specifieke domein.

2. Onboarding duurt langer dan het zou moeten Een codebase die vol zit met 'zo doen we het hier nu eenmaal' zonder duidelijke motivatie, is een codebase die zijn eigen complexiteit heeft gecreëerd. Soms is opruimen radicaler dan refactoren.

3. Discussies gaan over regels, niet over oplossingen Als je team meer energie steekt in het bewaken van conventions dan in het nadenken over de daadwerkelijke uitdaging, is er iets scheef gegroeid.

Het framework: wanneer breken, wanneer bewaken

Okay, dus je wil een heilig huisje omver gooien. Maar hoe weet je of dat slim is of roekeloos? Hier is een eenvoudig framework dat we bij PiratePad hanteren:

Stap 1: Begrijp de oorsprong

Vraag jezelf af: waarom bestaat deze regel? Als niemand in je team het antwoord weet, is dat al veelzeggend. Duik in de git history, de oude ADR's (Architecture Decision Records), of vraag het de meest ervaren persoon in de ruimte. Pas als je begrijpt waartoe een conventie dient, kun je beoordelen of ze nog steeds nuttig is.

Stap 2: Definieer het probleem dat je wil oplossen

Innovatie om de innovatie is zinloos. Welk concreet probleem lost jouw alternatieve aanpak op? Schrijf het op. Letterlijk. Als je het niet in twee zinnen kunt verwoorden, is je idee misschien nog niet rijp genoeg.

Stap 3: Isoleer het experiment

Breek nooit een conventie in de kern van je productie-omgeving zonder vangnet. Gebruik feature flags, branch-gebaseerde experimenten of een apart sandbox-project. De piraten-mentaliteit betekent niet dat je je schip tot zinken brengt — het betekent dat je durft te navigeren in onbekend water, maar wel met een reddingsvest aan.

Stap 4: Meet het resultaat eerlijk

Dit is waar veel teams de mist ingaan. Ze breken een regel, het werkt 'best wel oké', en dan wordt de nieuwe aanpak de nieuwe ongefundeerde conventie. Stel van tevoren meetbare criteria op: snelheid, foutpercentage, developer experience, onderhoudbaarheid. En wees eerlijk als het experiment faalt.

Stap 5: Documenteer de keuze

Als je besluit af te wijken, leg dan vast waarom. Niet voor de bureaucratie, maar voor het team dat er over twee jaar mee werkt. Een ADR van vijf regels kan uren aan verwarring voorkomen.

Inspiratie uit de Nederlandse techscene

Een kleine greep uit aanpakken die bewust ingingen tegen de gevestigde orde:

• Monorepo's voordat het cool was: Meerdere Nederlandse scale-ups kozen jaren geleden voor een monorepo-structuur toen de consensus nog duidelijk in de richting van aparte repositories wees. Ze deden dat omdat hun teams klein waren en context-switching duur. Inmiddels heeft de rest van de industrie ze ingehaald.

• GraphQL weggooien voor simplere REST: Een Amsterdams SaaS-bedrijf stapte over van GraphQL terug naar REST nadat bleek dat hun API-complexiteit niet opwoog tegen de overhead van het schema-beheer. Soms is teruggaan het meest progressieve wat je kunt doen.

• Geen CI/CD voor kleine projecten: Klinkt als ketterij, maar voor sommige interne tooling-projecten is een uitgebreide pipeline meer overhead dan het waard is. Een team dat dit bewust koos, kon daardoor sneller itereren op hun interne dashboards.

De rode draad? Allemaal bewuste keuzes, niet luie shortcuts.

De valkuil: anarchie zonder discipline

Hier moet je eerlijk zijn tegen jezelf en je team. Er is een groot verschil tussen doordacht afwijken van een conventie en regels negeren omdat je ze niet begrijpt of niet wil leren. De piraten-mentaliteit werkt alleen als je de kaart kent voordat je hem verscheurt.

Junior developers die best practices overslaan omdat ze 'te omslachtig' lijken, bouwen technische schuld. Ervaren teams die bewust kiezen voor een alternatieve aanpak op basis van context en bewijs, bouwen iets nieuws. Het verschil zit in kennis, intentie en communicatie.

Zorg ook dat je team aligned is. Eén iemand die zijn eigen regels schrijft zonder draagvlak creëert chaos. Anarchie als teamsport, met consensus en transparantie, is iets heel anders.

Slotgedachte: rebels met een reden

De beste codebases die ik ken zijn niet de netste of de meest conventionele. Het zijn de codebases die duidelijk laten zien waarom bepaalde keuzes zijn gemaakt — ook als die keuzes onorthodox zijn. Ze vertellen een verhaal van een team dat nadacht, experimenteerde, en eerlijk was over de uitkomst.

Dus de volgende keer dat iemand zegt 'maar zo doe je dat gewoon niet', stel dan de vraag: waarom eigenlijk niet? Misschien is het antwoord overtuigend genoeg om de conventie te respecteren. Of misschien is het het startpunt van iets dat de hele industrie over drie jaar als vanzelfsprekend beschouwt.

Bij PiratePad hopen we op het laatste.