Startup mentaliteit: laat het eerst een probleem worden

"Maar wat als er 10.000 gebruikers tegelijk inloggen?" "We moeten het RAM-gebruik van dit script optimaliseren." "Laten we eerst een abstractielaag bouwen voor als we later van database willen wisselen." Herken je deze gesprekken? Ik wel. En ik heb geleerd om er niet meer aan mee te doen.

De verkeerde prioriteiten

Als developers hebben we een natuurlijke neiging om problemen te voorkomen. We denken vooruit, anticiperen op edge cases, en bouwen systemen die kunnen schalen naar miljoenen gebruikers. Klinkt professioneel, toch?

Het probleem is: de meeste van die problemen gebeuren nooit. We besteden uren, dagen, soms weken aan het optimaliseren van code die misschien drie keer per dag wordt aangeroepen. We bouwen complexe abstractielagen voor flexibiliteit die we nooit nodig hebben. We schrijven uitgebreide documentatie voor functies die niemand ooit zal aanpassen.

De "blaffende honden" techniek

Ik noem het de "blaffende honden" techniek, gebaseerd op het Engelse spreekwoord "let sleeping dogs lie". Het principe is simpel:

Dat script dat 50MB RAM gebruikt in plaats van 10MB? Boeie. Je server heeft 4GB. Als het ooit een probleem wordt, merk je het vanzelf en kun je het dan optimaliseren met concrete data over waar de bottleneck zit.

Die database query die niet geïndexeerd is? Laat maar. Als de tabel ooit groot genoeg wordt dat het een probleem is, voeg je de index dan toe. Kost je 5 minuten en je hebt dan echte performance metrics om mee te vergelijken.

Waarom dit werkt

• 1. Snelheid: Je levert features af in een fractie van de tijd. Terwijl anderen nog aan het architecturen zijn, heb jij al drie iteraties gedaan op basis van echte gebruikersfeedback.
• 2. Focus op wat telt: Je energie gaat naar features die gebruikers daadwerkelijk nodig hebben, niet naar hypothetische problemen die misschien nooit optreden.
• 3. Betere beslissingen: Als je een probleem oplost wanneer het zich voordoet, heb je concrete data. Je weet precies wat de bottleneck is, hoeveel impact het heeft, en wat de beste oplossing is.
• 4. Minder technische schuld: Ironisch genoeg leidt deze aanpak vaak tot minder complexiteit. Geen overbodige abstracties, geen dode code voor features die nooit zijn gebouwd.

Een praktijkvoorbeeld

Laatst bouwde ik een import-functie voor grote Excel-bestanden. De "traditionele" aanpak zou zijn: queue system opzetten, workers configureren, progress tracking bouwen, error handling voor elk mogelijk scenario.

Wat ik deed: een simpel PHP script dat het bestand regel voor regel verwerkt. Geen queue, geen workers. Duurde twee uur om te bouwen in plaats van twee dagen.

"Maar wat als het bestand te groot is?" Dat zien we dan wel. Tot nu toe, na maanden in productie: geen enkel probleem. De grootste import was 5.000 regels en duurde 30 seconden. Perfect acceptabel.

Als er ooit een klant komt met een bestand van 100.000 regels? Dan bouw ik de queue. Met concrete requirements, concrete performance metrics, en in veel minder tijd omdat ik precies weet wat ik nodig heb.

Wanneer WEL vooruit denken?

Dit betekent niet dat je helemaal niet vooruit mag denken. Er zijn uitzonderingen:

• ✓ Security: Hier mag je niet wachten tot het een probleem wordt. Sanitize input, hash passwords, valideer alles.
• ✓ Data integriteit: Database constraints, foreign keys, unique indexes. Deze kosten weinig moeite en voorkomen echte problemen.
• ✓ Fundamentele architectuur: Als je weet dat je microservices nodig hebt, begin er dan mee. Maar alleen als je het echt weet, niet als je het vermoedt.

Dit is de mentaliteit die ik meeneem in elk project. Niet roekeloos, maar pragmatisch. Niet lui, maar efficiënt. En het werkt.