Twintig jaar leren waar dingen stukgaan.

Hoe ik hier terechtkwam

De computers kwamen eerst. Ik ben ertussen opgegroeid en had er zelf een toen ik acht was, zocht het al doende uit, en rond mijn dertiende was wel duidelijk welke kant het op ging. Er geld mee verdienen duurde langer.

Het eerste vak was lassen. Twee jaar ambulances bouwen bij een voertuigbouwer: chassisdelen, montage, het soort werk waarbij een slechte las geen kwestie van smaak is. Het leerde me iets dat blijft hangen. Wat je maakt moet het houden onder belasting, en het valt iedereen op wanneer dat niet zo is.

Daarna kwam de carrière in software, van onderaf opgebouwd.

Eerst systemen en netwerken. Vier jaar Linux- en Windows-beheer, firewalls, en VoIP-telefonie tot op protocolniveau: SIP, H.323, Asterisk, plus de client-serverarchitectuur eromheen en het derdelijns supportwerk waar je ontdekt hoe productie er om drie uur ’s nachts echt uitziet.

Daarna de software die erop draait. Vier jaar als lead developer: CMS- en e-commerceplatformen, maatwerkbackends, APIs en realtime systemen, terwijl ik tegelijk de servers beheerde waar ze op stonden. Ergens daar had ik een message bus nodig die niet bestond, dus schreef ik er een: HexxoreCore, distributed, met een eigen bij IANA geregistreerde poort. Dat is ongeveer het moment waarop het bouwen van het ontbrekende gereedschap ophield als omweg te voelen en het werk zelf werd.

Daarna de cloud en de automatisering die het geheel in productie zet.

Waarom die volgorde uitmaakt

Het waardevolle is niet de lijst met technologieën. Het is weten waar het echt misgaat. Zelden in het slimme stuk in het midden. Veel vaker is het de deploy, de migratie, de koppeling die het begeeft zonder iets te melden, of de ongemakkelijke ontdekking dat niemand ooit heeft opgeschreven wat het systeem zou moeten doen.

Het was altijd software waar mensen op leunden. Het soort dat stilletjes iemands bedrijfsvoering draaiende houdt, waar een slechte middag voor het systeem een slechte middag is voor iedereen die het gebruikt, en waar “bij mij werkt het” geen antwoord is waar iemand iets aan heeft.

Doordat ik het in die volgorde heb geleerd, breng ik iets van idee tot draaiend systeem zonder het halverwege over de schutting te gooien. De ontwerpkeuzes worden gemaakt door iemand die de pieper daarna ook zelf draagt.

Het ontbrekende gereedschap bouwen

Er zit een patroon in hoe ik werk dat het benoemen waard is, want daar komt het meeste van wat ik weet vandaan.

Het werk bestaat dagelijks uit het koppelen van bedrijfssystemen die nooit voor elkaar zijn ontworpen en het automatiseren van het handwerk ertussen. Steeds kwam dezelfde broze lijmcode terug: hier een script, daar een geplande taak, niets dat achteraf kon vertellen wat er nu eigenlijk was gebeurd. In plaats van die lijm voor de vijfde keer te bouwen, bouwde ik wat er had moeten zijn: echte procesautomatisering, met een verslag van elke uitvoering en een zinnige plek voor een menselijke beslissing.

Toen werden AI-coding-agents goed, en verschoof het knelpunt. De agents konden het werk doen; wat ze niet konden was alles wat een team zonder nadenken doet. Een gedeeld beeld houden van wat er loopt. Merken wanneer iets vastloopt. Inschatten wanneer er een mens bij moet. Ik probeerde de voor de hand liggende oplossingen. Een scherm vol terminals, per tabblad een agent, scripts om opdrachten in de wachtrij te zetten. Elke versie had hetzelfde gat: geen gedeelde werkomgeving, dus elke agent was een solonummer, en ik was het enige dat het overzicht bij elkaar hield. Dat werkt totdat je even wegkijkt. Dus bouwde ik dat ook, omdat ik verder wilde bouwen mét agents in plaats van ondanks agents.

Zo werken veranderde mijn idee over nog iets. Zodra de kosten om een kleine, goed afgebakende dienst uit te rollen ver genoeg dalen, hebben veel problemen helemaal geen grote software meer nodig. Ze hebben iets kleins nodig, netjes uitgerold, dat iemand ook echt kan draaien zonder platformteam.

Niets hiervan begon als een marktkans. Het waren stuk voor stuk problemen waar ik steeds opnieuw voor betaalde. Het nuttige daaraan voor een klant: de opvattingen die ik meebreng naar jouw project zijn opvattingen waar ik in mijn eigen werk mee heb moeten leven.

Hoe ik bouw

De voorkeur gaat altijd naar solide boven slim. Dit zijn dingen waar andere mensen op leunen, waardoor soliditeit het product is in plaats van een belasting erop. In de praktijk: tests die vóór de code geschreven zijn, expliciete state machines voor alles wat lang loopt, en externe systemen achter interfaces zodat een leverancier vervangen kan worden zonder herbouw.

Het betekent ook dat de ondankbare garanties niet ter discussie staan: logging, back-ups, metrics, monitoring, en een audit trail die kan beantwoorden wat er precies is gebeurd, en wanneer. Dat laatste telt meer dan ooit wanneer degene die handelde een agent was en geen mens.

Ik ben een voorstander van open source. Het is waar ik het vak op heb geleerd en waar ik het eerst naar grijp. Dat gezegd hebbende: niet alles wat ik bouw is zelf te hosten, en dat zeg ik liever ronduit dan dat ik anders suggereer. Wat wel constant is, is goed nadenken over lock-in voordat we een afhankelijkheid aangaan, en eerlijk zijn over de afhankelijkheden waar we niet makkelijk vanaf komen.

Samenwerken met Hexxore

Hexxore neemt engineeringwerk aan: software bouwen uit een ruw idee, een platform rechttrekken dat is afgedreven, systemen koppelen die jaren geleden al met elkaar hadden moeten praten, of het handwerk daartussen automatiseren. Doordat we onze eigen infrastructuur draaien komt het advies voort uit het zelf dragen van de gevolgen, niet uit een presentatie.

Heb je iets dat gebouwd moet worden? Dan hoor ik het graag.