Als je lang genoeg met softwareontwikkeling bezig bent, ga je patronen herkennen. Eén daarvan is dat je grofweg twee soorten developers hebt. Dat zijn geen harde labels en het is zeker niet zwart-wit, maar in de praktijk zie je wel duidelijke verschillen in hoe mensen werken en denken.
Aan de ene kant heb je de developers die vooral gericht zijn op snelheid. Gewoon beginnen, iets werkend krijgen en van daaruit verder bouwen. Aan de andere kant heb je developers die eerst willen begrijpen wat ze bouwen, hoe het in elkaar zit en hoe het zich op de lange termijn gaat gedragen. Ik noem ze hackers en architecten. Niet omdat de één beter is dan de ander, maar omdat ze allebei op een ander moment het best tot hun recht komen.
Snelheid als uitgangspunt
De hacker denkt vanuit beweging. Het doel is simpel: iets werkend krijgen. Niet over een paar maanden, maar vandaag. Of het perfect is, is op dat moment minder relevant. Het gaat erom dat je iets hebt waar je mee verder kunt, waar je feedback op kunt krijgen en dat je kunt aanpassen als dat nodig is.
Dat type developer zie je vooral in omgevingen waar nog weinig vaststaat, zoals bij startups. Nieuwe technologieën, markten die nog gevormd moeten worden, producten die nog geen duidelijke vorm hebben. In dat soort situaties werkt het niet om alles eerst uit te denken. Je moet eerst bouwen om te ontdekken wat werkt.
Het nadeel daarvan wordt meestal pas later zichtbaar. Dingen die snel gebouwd zijn, zijn vaak niet ontworpen om lang mee te gaan. Er ontstaat zogenoemde technische schuld, systemen worden lastig aan te passen en op een gegeven moment loop je tegen grenzen aan. Dan moet je alsnog terug om dingen opnieuw op te zetten, maar dat moment ligt vaak verder in de toekomst.
Ook bij Billink was dat jarenlang logisch. Eerst moest er iets werkends staan, integraties moesten live, nieuwe flows getest worden en klanten geholpen worden. Pas later merk je hoeveel impact vroege technische keuzes hebben op schaalbaarheid, onderhoud en snelheid van doorontwikkeling. Als ik nu de keuzes van toen zou kunnen terugdraaien, kan ik gemakkelijk een A4 volschrijven.
Structuur als fundament
De architect kijkt op een andere manier naar hetzelfde probleem. Niet zozeer naar hoe snel iets werkt, maar naar hoe goed het blijft werken. Hoe zorg je ervoor dat een systeem schaalbaar is, dat het onderhoudbaar blijft en dat je over een paar jaar nog begrijpt wat er gebouwd is? Dat type developer komt beter tot zijn recht in een omgeving waar al meer duidelijkheid is. Een omgeving waar processen bestaan, waar systemen met elkaar moeten samenwerken en waar zaken als security en governance een grotere rol spelen. Dan wordt het belangrijker om vooraf na te denken over keuzes, omdat de impact van die keuzes groter is.
Maar ook hier zit een keerzijde aan. Te veel focus op structuur kan ervoor zorgen dat je te langzaam beweegt. Dat je blijft nadenken, risico’s probeert uit te sluiten en daardoor minder snel tot iets concreets komt. En zonder iets concreets is het lastig om te leren en verbeteren.
Groei dwingt tot verandering
Als je kijkt naar hoe bedrijven zich ontwikkelen, zie je dat deze twee manieren van werken elkaar in fases afwisselen. In de beginfase overheerst bijna altijd de hacker mentaliteit. Er moet iets komen, en snel. Perfectie speelt nauwelijks een rol, omdat er simpelweg nog te veel onbekend is.
Naarmate een bedrijf groeit, ontstaat er behoefte aan meer structuur. Systemen moeten beter op elkaar aansluiten, het aantal gebruikers neemt toe en de impact van fouten wordt groter. In die fase zie je vaak dat hackers en architecten naast elkaar gaan werken, wat niet altijd vanzelf soepel gaat, maar wel nodig is.
In een latere fase verschuift de nadruk vaak naar architectuur. Stabiliteit, schaalbaarheid en veiligheid worden belangrijker dan snelheid. Het risico daarvan is dat innovatie naar de achtergrond verdwijnt en dat alles trager wordt. Daarom zie je dat bedrijven die blijven vernieuwen, bewust ruimte maken voor snelheid, ook als ze al volwassen zijn.
Nieuwe technologie, oude patronen
Wat interessant is, is dat dit patroon zich blijft herhalen bij elke nieuwe technologie golf. In de beginfase van het internet waren het de snelle bouwers die voorop liepen. Hetzelfde zag je later bij mobile en andere ontwikkelingen. En nu gebeurt dat opnieuw met AI. De technologie is anders, maar de dynamiek is vergelijkbaar. In het begin draait het om ontdekken, experimenteren en snel schakelen. Dan zijn het opnieuw de mensen die durven bouwen zonder alles vooraf dicht te timmeren die het tempo bepalen.
Tegelijkertijd verandert AI wel iets fundamenteels aan de manier waarop we naar deze rollen kijken. Waar snelheid vroeger vaak ten koste ging van kwaliteit, zie je nu dat die twee dichter bij elkaar komen. Een developer die snel werkt, kan met behulp van AI ook sneller refactoren, documenteren en structuur aanbrengen. De output is daardoor minder rommelig dan vroeger, zonder dat de snelheid volledig verloren gaat.
Aan de andere kant kunnen architecten sneller analyseren, keuzes maken en systemen overzien, omdat een deel van het werk wordt ondersteund. Maar dat betekent niet dat architectuur minder belangrijk wordt. Integendeel. Omdat het makkelijker wordt om veel te bouwen, neemt de complexiteit ook sneller toe. En juist dan wordt het belangrijker om duidelijke kaders te hebben.
De vraag verschuift daarmee. Het gaat minder om of je iets kunt bouwen, en meer om of je de juiste dingen bouwt en of ze passen binnen het geheel. Dat is een vraag die je niet alleen met tools kunt beantwoorden.
De balans verschuift, maar verdwijnt niet
Wat je nu ziet ontstaan, is geen vervanging van de ene rol door de andere, maar een verschuiving in hoe ze samenwerken. De voorgaande tegenstelling tussen snelheid en structuur wordt minder scherp, omdat beide kanten sterker worden door dezelfde technologie. Hackers kunnen sneller en netter bouwen dan voorheen. En architecten kunnen sneller sturen en richting geven. Maar de onderliggende verschillen blijven bestaan. De één denkt vanuit beweging en experiment, de ander vanuit samenhang en duurzaamheid.
En dat betekent dat organisaties nog steeds dezelfde uitdaging hebben als voorheen: weten wanneer je welke benadering nodig hebt.
De vraag is een beetje of we hiermee een nieuw tijdperk ingaan. Wat je nu ziet, voelt in ieder geval vergelijkbaar met eerdere momenten waarop technologie ineens een sprong maakte en de spelregels tijdelijk veranderden. Tegelijkertijd denk ik niet dat de basis echt verandert. Je zult altijd mensen houden die vanuit snelheid en experiment denken, en mensen die juist bezig zijn met structuur en beheersbaarheid. Voor mijn gevoel blijven die twee werelden gewoon bestaan. Alleen zie je nu dat de balans even verschuift. In een fase waarin alles nieuw is en nog ontdekt moet worden, is er meer ruimte voor snelheid en experiment. Dan komen de hackers vanzelf weer wat meer naar voren. Totdat het moment komt waarop alles weer moet landen, en structuur opnieuw belangrijker wordt.