Gegenereerde tests
Als ik collega’s spreek over de voordelen van LLMs, dan is meestal één van de eerste toepassingen die ze voor zich zien: tests laten genereren door AI. Ik begrijp waar die behoefte vandaan komt. Want tests achteraf schrijven is een rotklusje. Achteraf denk je als ontwikkelaar namelijk al te weten dat je code doet wat ‘ie moet doen. Zulke tests fungeren als een soort administratie van de handmatige tests die je tot die conclusie leidden. En wie houdt er nu van zijn administratie bijwerken? – En toch geloof ik niet dat het een goed idee is om AI in te zetten om tests te genereren.
"Trunk"
Op het virtuele bord van onze Retrospective verscheen in de kolom kan beter een sticky met maar één woord erop: ’trunk’. Na een aardige tijd trunk-based te hebben ontwikkeld, bekende een collega de werkwijze nog altijd niet helemaal onder de knie te hebben.
De beste boeken over software ontwikkeling die ik in 2025 las
A leidt tot B en B leidt tot C, dus als we C willen, moeten we A. Dat is hoe ons denken er normaal gesproken ongeveer uitziet, en dat is helemaal prima. Maar ja, weet je, de werkelijkheid werkt dus niet zo. Want in de werkelijkheid leidt A niet alleen tot B maar ook tot D, E en F, en dat zijn dingen die een negatieve impact op C (en B en misschien ook op A) hebben. Soms is het zelfs beter om A en B helemaal niet te doen, of juist het tegenovergestelde, als we C willen bereiken. Dat is hoe de werkelijkheid wél werkt. Maar ja, ga dat maar eens aan je collega’s uitleggen.
23 introducties
Onlangs sprak ik op Noordertest, een testconferentie in Groningen. Een aantal weken van tevoren kreeg ik een verzoek in mijn mail om een pakkend tekstje te schrijven waarmee ik kon worden geïntroduceerd. – Ik schreef er drieëntwintig.
Refactoren is als fitnessen
Laatst zei mijn vrouw tegen me: “Hé, je vetkwab is weg!” Maar toen keek ze iets langer en vervolgde: “Nou ja, bijna.” – Wat ik bedoel te zeggen is: het gaat de goede kant op. Ik doe wat aan lichaamsbeweging de laatste tijd, een beetje fitness. Het deed me, omdat ik een beroepsdeformatie heb, aan refactoren denken.
Waarom schrijven?
Waarom zou je schrijven? Waarom een blog bijhouden? Er is zoveel te doen, zoveel deadlines om te halen. Zou je je kostbare tijd niet beter aan programmeren kunnen besteden?
Oppervlakkige en diepe modules
Eén van de interessantste ideeën die John Ousterhout naar voren brengt in A Philosophy of Software Design, is de notie van oppervlakkige en diepe modules. Een module is oppervlakkig als deze veel (onnodige) complexiteit aan de gebruiker van de module openbaart. Ze is diep als ze die complexiteit juist verbergt.
Het geünificeerde domeinmodel, revisited
Binnen applicatie a is het zinvol om van conceptitems te spreken, binnen applicatie b niet. Binnen applicatie b is het zinvol om van de P-waarde (moeilijkheidsgraad) van een item te spreken, binnen applicatie a niet. Heeft het(zelfde) woord “item” dan dezelfde betekenis in binnen de context van beide applicaties, of niet? Moet het Item in het geünificeerde domeinmodel de property’s IsConcept of PValue bevatten?
Hoe heb je het volgehouden?
Software ontwikkelen is niet makkelijk, het is van zichzelf al niet makkelijk en het wordt nog moeilijker omdat je met mensen werkt en mensen zijn nooit makkelijk.