Software Development is voor mij meer dan code schrijven. Het gaat om het vertalen van een probleem naar software die begrijpelijk, betrouwbaar en duurzaam blijft wanneer een product verder groeit.
Technologie is daarin een middel. De echte uitdaging zit vaak in het maken van de juiste keuzes: wat bouwen we wel, wat bouwen we bewust niet en hoe zorgen we ervoor dat een ander het systeem later nog steeds begrijpt?
Wat is Software Development?
Software Development omvat het ontwerpen, bouwen, testen, deployen en onderhouden van software. In de praktijk betekent dat voor mij dat ik continu beweeg tussen code, architectuur, infrastructuur en het domein waarvoor we software ontwikkelen.
Mijn focus ligt voornamelijk op backend development. Daar werk ik aan systemen waarin data, integraties en bedrijfslogica samenkomen. Vooral wanneer meerdere systemen met elkaar moeten samenwerken, wordt structuur belangrijk.
Ik probeer software daarom altijd vanuit drie principes te benaderen:
Simpliciteit: niet complexer maken dan nodig.
Structuur: verantwoordelijkheden en grenzen duidelijk houden.
Duurzaamheid: keuzes maken die technisch en bedrijfsmatig op langere termijn logisch blijven.
Belangrijke dingen om te weten
Goede software ontstaat niet automatisch door moderne technologie te gebruiken.
Een microservice-architectuur is bijvoorbeeld niet per definitie beter dan een monoliet. Kafka is niet automatisch de juiste oplossing omdat een systeem events verwerkt. En een database die technisch uitstekend is, kan bedrijfsmatig alsnog de verkeerde keuze zijn.
Ik kijk daarom eerst naar het probleem en daarna pas naar de technologie.
Daarbij vind ik een aantal zaken belangrijk.
Begrijp het domein eerst
Voordat ik een technische oplossing ontwerp, wil ik begrijpen waarom het probleem bestaat. Zonder die context is het makkelijk om technisch goede software te bouwen die uiteindelijk het verkeerde probleem oplost.
Maak verantwoordelijkheden duidelijk
Zeker binnen distributed systems wil ik precies weten welke service waarvoor verantwoordelijk is, wie eigenaar is van data en wat er gebeurt wanneer communicatie tussen systemen mislukt.
Denk na over consistentie
Niet iedere operatie hoeft direct consistent te zijn. Vanuit mijn ervaring met Immediate en Eventual Consistency kijk ik bewust naar waar synchrone verwerking noodzakelijk is en waar processen beter asynchroon kunnen verlopen.
Software stopt niet bij deployment
Logging, monitoring, testing, CI/CD en infrastructuur zijn voor mij onderdeel van softwareontwikkeling. Een applicatie die alleen lokaal goed werkt, is nog geen goed softwaresysteem.
Hoe ik Software Development gebruik
Mijn manier van ontwikkelen begint meestal met het terugbrengen van een probleem naar de essentie.
Wat moet het systeem daadwerkelijk doen? Welke data is belangrijk? Welke afhankelijkheden bestaan er? En welke onderdelen kunnen veranderen?
Daarna probeer ik verantwoordelijkheden zo duidelijk mogelijk te scheiden.
In backend-systemen betekent dat bijvoorbeeld dat ik werk met Java of Kotlin, Spring of Quarkus en afhankelijk van het probleem technologieën zoals Redis, Kafka, AWS of relationele en document databases inzet.
Bij distributed systemen kijk ik daarnaast expliciet naar communicatie tussen services. Soms is REST de eenvoudigste oplossing. In andere situaties past een event-driven aanpak beter.
Het belangrijkste is voor mij dat de architectuur het probleem ondersteunt en niet andersom.
Waar ik Software Development heb toegepast
Software Development loopt eigenlijk door mijn volledige carrière heen, maar mijn recente projecten laten vooral zien hoe mijn rol zich steeds meer van alleen implementatie naar technische en architecturale verantwoordelijkheid heeft ontwikkeld.
ANWB
Bij ANWB werk ik binnen het Car Platform aan een backend-platform dat veel externe databronnen verwerkt.
Daar heb ik een bestaande Spring Kotlin-oplossing verder ontwikkeld richting een event-driven architectuur. Onder andere door verantwoordelijkheden binnen het systeem duidelijker te scheiden en een asynchrone task scheduler te ontwikkelen met Kotlin Coroutines en Redis.
Ook heb ik de overstap naar Redis Streams geleid voor betrouwbaardere verwerking van berichten en gewerkt aan AWS-infrastructuur en Kong API Gateway.
Hier zit Software Development voor mij niet alleen in het schrijven van functionaliteit, maar juist in het continu verbeteren van de manier waarop het gehele systeem functioneert.
Port of Amsterdam
Bij Port of Amsterdam werkte ik als Senior Lead Java Backend Developer aan verschillende bedrijfskritische applicaties voor havenoperaties.
Daar lag de verantwoordelijkheid niet alleen bij nieuwe functionaliteit, maar ook bij betrouwbaarheid en onderhoudbaarheid van bestaande systemen.
Dat heeft mij opnieuw laten zien dat goede Software Development vaak niet betekent dat je iets volledig opnieuw moet bouwen. Soms zit de meeste waarde juist in het gecontroleerd verbeteren van wat er al staat.
Eigen SaaS-platform
Binnen een eigen freelanceproject heb ik een SaaS-platform ontwikkeld met vijf microservices die via Kafka met elkaar communiceren.
Daarbij gebruikte ik het Saga Pattern om processen over verschillende services heen consistent af te handelen. Daarnaast bouwde ik een aparte Go-service waarmee gedistribueerde processen gevolgd konden worden.
Hier kwamen Software Development en Software Architecture sterk samen. Niet alleen nadenken over een individuele service, maar over het gedrag van het complete systeem.
Mijn recente ervaring met Software Development
Mijn recente ervaring zit voornamelijk in Java en Kotlin backend-systemen waarbij distributed systems, event-driven architecturen en data-integriteit centraal staan.
Bij ANWB werk ik veel met Spring Kotlin, Redis Streams, Kotlin Coroutines, AWS en Kong. Daarbij gaat mijn aandacht steeds vaker naar vraagstukken die boven individuele code uitstijgen: schaalbaarheid, foutafhandeling, verantwoordelijkheden tussen componenten en de evolutie van een platform.
Door eerdere projecten met Java, Quarkus, Kafka en het Saga Pattern heb ik daarnaast veel praktijkervaring opgebouwd met verschillende vormen van consistentie binnen microservices.
Mijn manier van ontwikkelen is daardoor steeds meer gericht op één vraag:
Hoe bouwen we vandaag iets dat we morgen nog steeds eenvoudig kunnen begrijpen en veranderen?
Veelgestelde vragen die ik krijg over Software Development
Wanneer is software volgens jou goed?
Wanneer het het probleem oplost zonder onnodige complexiteit. Goede software moet niet alleen vandaag werken, maar ook begrijpelijk en aanpasbaar blijven.
Kies je liever voor een monoliet of microservices?
Geen van beide standaard. Ik kijk eerst naar het domein, schaalbaarheid en de verantwoordelijkheden binnen het systeem. Soms is een goed opgebouwde monoliet simpelweg de betere oplossing.
Hoe bepaal je welke technologie je gebruikt?
Vanuit het probleem. Niet vanuit wat technisch interessant is. Ik gebruik liever een eenvoudige bewezen oplossing dan een complexe technologie waarvoor geen duidelijke noodzaak bestaat.
Hoe belangrijk is architectuur tijdens development?
Heel belangrijk, maar architectuur moet development ondersteunen. Ik probeer daarom voldoende structuur neer te zetten zonder het systeem vooraf volledig dicht te ontwerpen.
Wat heb je door de jaren heen vooral veranderd aan je manier van ontwikkelen?
Ik schrijf minder snel code.
Ik probeer tegenwoordig eerst beter te begrijpen waar het probleem vandaan komt, welke verantwoordelijkheid ergens hoort en wat de gevolgen van een keuze op langere termijn zijn. Dat voorkomt uiteindelijk vaak meer werk dan direct beginnen met bouwen.