dotkarl

Overzicht

Mon, 01 Jan 0001 00:00:00 +0000

Een beknopt overzicht van alle praatjes die ik de afgelopen tijd heb gehouden.

De edele kunst van het pull request, Redux

Fri, 17 Jul 2026 07:48:34 +0200

Het praatje dat ik in 2024 op T-DOSE gaf, The art of the pull request, is onlangs op YouTube verschenen. Gezien mijn houding naar pull requests de afgelopen twee jaar is veranderd, leek het me een mooie gelegenheid om die ideeën nog eens te overdenken.

AI vs. ontwikkelaars

Fri, 10 Jul 2026 09:28:24 +0200

Kijk uit, merkte mijn manager op: een groot deel van haar sollicitanten was aan het solliciteren geslagen precies omdat hun huidige werkgever vol op AI had ingezet. De ontwikkelaars voelden zich niet meer thuis in die nieuwe wereld. Ze hadden er een hekel aan enkel nog code te reviewen, ze wilden weer terug code met de hand te schrijven. Hebben die ontwikkelaars het mis? Blijven zij achter?

De geschiedenis van programme(ercultu)ren

Fri, 03 Jul 2026 09:28:09 +0200

Vraag tien programmeurs naar de beste manier om een probleem op te lossen, en je krijgt tien verschillende antwoorden. Conclusie: ‘It depends.’ Maar stel tien programmeurs de vraag wat programmeren precies inhoudt, en je krijgt waarschijnlijk óók tien verschillende antwoorden. Bij de geboorte van softwareontwikkeling, in de jaren ‘50, kon het gebrek aan consensus nog worden geweten aan de onvolwassenheid van het vakgebied. Maar anno 2026 liggen de visies op de aard van programmeren nog steeds even ver uit elkaar. It depends, blijkbaar – maar waarvan dan?

Twee soorten verantwoordelijkheid

Fri, 26 Jun 2026 07:05:31 +0200

Programmeren en testen horen bij elkaar, het zijn twee kanten van dezelfde munt – en die munt is: productierijpe software opleveren. Daaruit volgt dat de activiteiten van het programmeren en testen verenigd moeten worden in één persoon – en die persoon is de ontwikkelaar. Dit wijkt af van de traditionele rolverdeling, waarin programmeurs programmeren en testers testen. Wat is dan nog de verantwoordelijkheid van de tester?

Genericiteit, specificiteit, complexiteit

Fri, 19 Jun 2026 06:15:32 +0200

Je zegt, alsof instinctief: een generieke component is beter dan een specifieke component, want een generieke component is herbruikbaar. Maar dat veronderstelt dat je weet welk deel van de verantwoordelijkheden generiek is en welke specifiek, en dat je deze netjes van elkaar kunt scheiden. Een specifieke component is eenvoudiger dan een generieke component, want een specifieke component hoeft alleen maar in specifieke omstandigheden te werken. Over het algemeen geldt: eenvoudig is beter dan complex. Dus is een specifieke component dan niet beter dan een generieke?

De woestijn en het bos

Fri, 12 Jun 2026 07:45:11 +0200

Bevinden we ons in een woestijn of in een bos? – Het antwoord op die vraag zal ons handelen bepalen. Woestijnnomaden begrijpen bosbewoners niet, en andersom. Woestijnnomaden wuiven afwerend: “Dat kan nooit!” Bosbewoners krabben aan hun hoofd: “Waarom zou je het ooit zo aanpakken?” Maar het kan wél, en het is logisch om het zó te doen, als de omgeving er naar is. Dat moeten we begrijpen van elkaar.

Twee doelen van een ontwikkelteam

Fri, 05 Jun 2026 07:52:16 +0200

Een softwareontwikkelteam heeft, in abstracto, twee doelen: vernieuwing en veiligheid. Een team bestaat daarom, zou je kunnen stellen, uit twee delen: ontwikkelaars en testers. Deze conceptualisatie van een ontwikkelteam is het gevolg van een vorm van reductionisme. Maar een team valt niet te reduceren tot haar samenstellende delen. Ze bestaat uit haar samenstellende delen plus hun vormen van interactie.

Conservatieve verandering

Fri, 29 May 2026 07:30:24 +0200

Hoe weet je of je het goed doet? Dat het niet beter kan? Ik ben van mening dat het onze professionele plicht is om van tijd tot tijd onze manieren van werken om te gooien. Omdat ik denk dat er betere manieren zijn, maar ook en vooral omdat we niet weten of de huidige manier van werken de beste is, als we deze niet regelmatig in vraag stellen. – Maar dan: de anderen.

Een tester of praten

Fri, 22 May 2026 07:37:34 +0200

Wij hebben geen tester in ons team. Niet omdat ik niet van testers hou (ik hou van testers), maar omdat het verkeerd gebruik van een tester dysfunctionele patronen in een team verbergt en in stand houdt.

Postmoderne code

Fri, 15 May 2026 10:50:50 +0200

Een collega stuurde me een code-snippet door met de vraag: Karl, hoe zit het met de nullability van deze property? Ik moest er enorm om lachen, want het antwoord op die vraag verschoof al naar gelang mijn ogen over die ene regel gleden. Alsof ik naar een postmodern kunstwerk keek, bedoeld om op interessante manieren te verwarren.

Worsteling

Fri, 08 May 2026 07:51:41 +0200

We betoogden tegen verschillende omgevingen voor ontwikkel, test, acceptatie en productie: dat is duur en bovendien nodeloos complex. Er is maar één omgeving die ertoe doet: productie. Maar om de wijzigingen naar productie klein en veilig te houden, kunnen we functionaliteit verbergen. – “Dat is valsspelen!” riep iemand in het publiek, de wanhoop nabij. “Je hebt nu alsnog een testomgeving, alleen dan op productie!”

De vergeten tester

Wed, 06 May 2026 07:50:09 +0200

Testen is cruciaal voor softwarekwaliteit. En toch, toen ik de kans kreeg een nieuw agile softwareteam samen te stellen, “vergat” ik de tester. Hoe verklaren we deze paradox? Hoe kan een tester tegelijkertijd zó belangrijk en toch ongewenst zijn?

Een tip voor testers

Fri, 01 May 2026 07:40:07 +0200

Elke softwareontwikkelaar weet dat hij zijn werk goed moet testen. Waarom glippen de meest voor de hand liggende bugs er dan toch doorheen? Omdat testen bij testers is belegd. Dat klinkt voor programmeurs verleidelijk efficiënt: waarom tijd besteden aan het schrijven van tests als iemand het werk toch nog naloopt? Deze taakverdeling nodigt uit tot lagere codekwaliteit en legt de pijn daarvan bij testers.

Behoefte aan een testlane

Fri, 24 Apr 2026 07:36:29 +0200

Als we met z’n allen met één ding bezig zijn, dan is onmiddellijk, voor iedereen, zichtbaar wat er al getest is en wat niet. Een testlane is een lapmiddel voor het eigenlijke probleem: dat we onvoldoende samenwerken. Daardoor weten we niet wie wat al heeft gedaan. Dáárom heb je behoefte aan een middel om daar inzicht in te verkrijgen.

Bezwaren tegen continuous deployment

Fri, 17 Apr 2026 08:30:38 +0200

Continuous deployment is: elke commit gaat meteen naar productie. Er is geen testomgeving, er is geen acceptatieomgeving; er zijn geen lang levende branches behalve de main branch, en die is gelijk met productie. – Waanzin! wil je roepen, dat kan nooit werken! – Oké. Waarom niet?

Uitrollen, vlak voor de demo

Fri, 10 Apr 2026 08:05:41 +0200

“Ik vind dat we niet meer uit moeten rollen vlak voor een demo,” zei een collega, “dat vond ik nogal spannend.” Liever had hij zichzelf nog wat extra tijd gegeven om zekerheid te krijgen dat de wijziging niet onbedoeld dingen stuk had gemaakt. Ik begrijp het sentiment van waaruit deze opmerking ontspringt. Maar het is in mijn beleving de verkeerde diagnose van de situatie.

Entity services en het contextprincipe

Fri, 03 Apr 2026 09:06:12 +0200

Een domein bestaat uit een aantal entiteiten. Voor een webwinkel zijn dat dingen als product, winkelwagentje en bestelling. Zulke entiteiten verwachten we terug te vinden in onze code: Product, ShoppingCart en Order. In veel codebases vinden we, naast deze entiteiten, corresponderende objecten: services. De logica rondom een product wordt afgehandeld in de ProductService, die van een winkelwagentje in een ShoppingCartService – en waar je de logica voor een bestelling kunt vinden, kun je vast wel raden. Het gedachteloos introduceren van dit soort entity services is me een doorn in het oog.

TDD en de testpiramide

Fri, 27 Mar 2026 08:03:21 +0100

Ik ruimde een boekenkast in op het werk, toen een collega me vroeg of ik wist hoe je een call naar een keyed service uit de IServiceProvider mockt. Nee, niet direct, zei ik. Maar waarom zou je dat überhaupt willen? Vanaf daar ontspon er een gesprek over Test-Driven Development, het ontwerp van code en de verschillende delen van de testpiramide.

Moeten refactorings ook gereviewd worden?

Fri, 20 Mar 2026 07:16:24 +0100

Niet elke codewijziging is gelijk. Sommige wijzigingen veranderen het gedrag van een systeem. Andere wijzigingen, refactorings, veranderen alleen de structuur en laten het gedrag gelijk. Zoals de meeste teams hun werk inrichten, met pull requests en formele code reviews, wordt elke wijziging door twee paar ogen bekeken. Maar is dat wel nodig?