“Software development is veel meer dan code maken. Natuurlijk begint het daar vaak wel mee. Je schrijft code, lost problemen op en bouwt door aan een product. Maar hoe langer ik aan een groot product werk, hoe duidelijker ik zie dat techniek ook gaat over keuzes maken. Over structuur. Over hoe je voorkomt dat één aanpassing ergens anders onverwacht iets omvertrekt.

Bij Somtoday werken mijn team en ik aan zo’n groot product. Technisch gezien is het nu nog een monoliet: één grote applicatie waarin alles met elkaar verbonden is. Dat heeft voordelen, want iedereen kent de structuur en je kunt er jarenlang op doorbouwen. Maar na twintig jaar ontwikkelen stapelt techniek zich op. Nieuwe oplossingen komen erbij, oude onderdelen blijven staan en op een gegeven moment merk je dat het steeds lastiger wordt om snel en veilig te vernieuwen.

Eén grote steen

Ik vergelijk die monoliet vaak met een oude stad. Er zitten mooie onderdelen in, maar de smalle straatjes en routes die ooit logisch waren, zitten nu soms in de weg. Bij software heb je gelukkig minder sentimentele waarde dan bij zo’n oude stad. Als iets slimmer kan, moet je durven kijken hoe je het opnieuw opbouwt.

Waar we met Somtoday naartoe willen, is een product dat niet meer uit één grote monoliet bestaat, maar uit kleinere onderdelen. Bakstenen in plaats van één enorme steen. Zo’n baksteen kun je optillen, aanpassen en verbeteren zonder dat je meteen de hele muur opnieuw hoeft te bouwen. Alleen; die bakstenen moeten wel met elkaar blijven samenwerken. Daar komt het cement om de hoek kijken.

Het cement tussen de blokjes

Dat is waar ik nu vooral mee bezig ben. Niet alleen code typen, maar meedenken over hoe die losse onderdelen straks met elkaar praten. Neem iets simpels als een leerling. Die leerling komt overal terug: bij aanwezigheid, cijfers, zorg en allerlei andere onderdelen van Somtoday. Als je die functionaliteiten losser van elkaar maakt, moeten ze nog steeds begrijpen dat ze het over dezelfde leerling hebben. Die communicatie tussen onderdelen goed ontwerpen, is misschien minder zichtbaar voor de gebruiker, maar wel cruciaal.

Ik zit nu vooral in het stadium waarin we de requirements uit bestaande software halen. AI mag de code lezen en kijken welke regels, relaties en volgordes daarin zitten. Daarna kun je gaan nadenken: als we dit opnieuw zouden neerzetten, hoe zouden we dat dan doen?

AI als sparringpartner

Ik onderzoek ook hoe AI kan helpen bij die technische vernieuwing. Niet door simpelweg te zeggen: hier is een lijst requirements, succes ermee. Zo werkt het volgens mij niet. AI werkt beter als je er echt mee in gesprek gaat. Je legt uit waarom iets zo werkt, welke relaties er zijn en waar de nuance zit. Dan kan AI veel beter achterhalen waarom iets op een bepaalde manier gebouwd moet worden.

Maar AI neemt het werk niet zomaar over. Je moet nog steeds begrijpen wat er onder water gebeurt. Als AI iets bouwt wat technisch klopt, maar niet past bij de richting die je op wilt, moet je kunnen bijsturen. Daarvoor moet je de technische taal nog steeds kennen. Je moet snappen wat bepaalde keuzes in code betekenen en welke gevolgen ze kunnen hebben.

Techniek is ook sociaal

Wat ik interessant vind, is dat deze vernieuwing niet alleen technisch is. De manier waarop teams werken, heeft invloed op hoe je software bouwt. Als je wilt dat teams sneller en zelfstandiger kunnen bewegen, moet de techniek daarin meegaan.

Dat was voor ons ook een belangrijke stap. Iedereen wist wel dat werken met zo’n grote monoliet nadelen had. Maar weten dat iets schuurt, is iets anders dan daadwerkelijk de stap zetten om het anders te doen. Soms is software engineering ook gewoon een sociaal beroep. Je moet collega’s meenemen, uitleggen waarom iets nodig is en samen een nieuw patroon vinden.

Ontwikkelaars zijn vaak gewoontedieren. Als een patroon eenmaal werkt, is het fijn om dat te blijven volgen. Oogkleppen op en focussen op de code. Bij dit soort vernieuwing hoef je die oogkleppen niet per se af te zetten, maar je moet ze wel iets de andere kant op draaien. Zodat je naar het juiste stukje kijkt.

Sneller waarde leveren

Het uiteindelijke doel is simpel: sneller waarde leveren zonder dat gebruikers daar last van hebben. Als een klant iets nodig heeft, wil je niet zeggen, “over drie dagen kunnen we misschien een release doen en dan moet iedereen opnieuw inloggen.” Je wilt kleine onderdelen kunnen aanpassen en live zetten terwijl de rest gewoon blijft draaien.

Dat betekent niet dat we morgen klaar zijn. Somtoday bestaat uit miljoenen regels code. Dat zet je niet even in één keer om. Klanten werken er gewoon mee door. Daarom zoeken we naar een manier om stap voor stap te vernieuwen, terwijl het product blijft draaien.

Blijf experimenteren

Mijn tip aan andere developers? Blijf experimenteren. Niet elk experiment wordt de oplossing, maar ook ontdekken wat níet werkt is waardevol. Juist door af en toe buiten je vaste patroon te stappen, leer je waar de echte verbetering zit.

Dat is voor mij ook wat dit werk leuk maakt. Je bouwt niet alleen aan code, maar ook aan de manier waarop je samen software maakt. En soms begint zo’n verandering gewoon met de vraag: moet dit echt nog steeds op de oude manier?"