Software Ontwikkelen on dotkarl

Pairing en theoriebouwen

Fri, 23 Oct 2026 08:02:45 +0200

Waarom zou je aan pair programming doen? Dan doen twee mensen het werk van één, dat is toch vreselijk inefficiënt! – Die zienswijze veronderstelt dat het doel van programmeren is om een werkend programma te produceren. Maar een werkend programma maakt nog geen goede software. Goede software is soft: eenvoudig aan te passen naar veranderende eisen en wensen.

Theoriebouwen (een schets)

Fri, 16 Oct 2026 07:55:37 +0200

Wat is programmeren? Een voor de hand liggend antwoord is: een programma schrijven. Wie tekst oplevert die door een compiler kan worden omgezet naar machine-instructies, die kunnen worden uitgevoerd om een bepaald doel te bereiken – die programmeert. Programmeren wordt in deze schets gekenmerkt door het opgeleverde eindproduct: het programma.

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.

Borrelpraat #2

Fri, 10 Oct 2025 08:47:35 +0200

Hij dronk cola, ik een biertje – maar verder zitten we op één lijn. Het duurde niet lang voordat het over de zoekindex ging – altijd die verdomde zoekindex. “Dat is al vanaf het begin een pijnpunt,” bekende ik. “En ik ben zelf onderdeel van het probleem geweest.”

Zoek en gij zult vinden

Fri, 05 Sep 2025 07:37:40 +0200

Soms duurt het ruim vier jaar voordat je eraan toekomt – maar: dotkarl kent nu eindelijk de mogelijkheid om blogs te doorzoeken. Woohoo!

Gaan we snel genoeg?

Fri, 01 Aug 2025 08:06:44 +0200

Sinds kort ben ik in van team gewisseld. Sinds die wissel mag ik mezelf met recht full stack developer noemen. Ik ben verantwoordelijk voor de back-end, de front-end – de database, de infrastructuur, security – de requirementsanalyse, de tests… Je kunt je voorstellen: het kan even duren voordat een (ogenschijnlijk) eenvoudige feature afgerond is. Af en toe maakt een knagend schuldgevoel zich dan ook meester van me: gaan we snel genoeg?

Feature branches belemmeren een beter begrip van koppeling

Fri, 09 May 2025 07:51:17 +0200

Laatst brak een kleine wijziging aan de back-end – die we zo snel mogelijk richting de testomgeving hadden gebracht – functionaliteit aan de front-end. Voor mijn collega was het een ideale gelegenheid om zijn bias voor Gitflow bevestigd te zien. “Dit zou nooit gebeurd zijn als we van feature branches gebruik hadden gemaakt!” concludeerde hij. – En niet onterecht, want het apart houden van de wijziging in kwestie zou de functionaliteit op testomgeving inderdaad intact hebben gehouden.

Wie is er bang voor adapterfuncties?

Fri, 04 Apr 2025 08:11:54 +0200

Adapters zijn een bekend ontwerppatroon in de softwareontwikkeling. Toch kwam deze oplossingsrichting niet onmiddellijk bij me op toen ik een stuk code in onze zoekindex begon te refactoren (om van de oorspronkelijke schrijver nog maar te zwijgen!). In plaats daarvan gaven onze eerste pogingen er blijk van koste wat kost te willen blijven werken met de “standaard”-functies. – Waarom?

Het ontologische argument

Fri, 21 Mar 2025 08:15:52 +0100

Onlangs pairde ik met een nieuwe collega. We hadden een refactortaak opgepakt om wat ondoorgrondelijke code rondom onze zoekindex te versimpelen. Ergens halverwege die refactorslag zei hij iets wat mijn aandacht trok.

Een kleine stap voor de code...

Fri, 21 Feb 2025 08:14:20 +0100

Toen een collega van me laatst vastliep op het omschrijven van wat authenticatielogica, sprong ik graag bij. Ik wist immers wat de juiste weg voorwaarts was: heel veel heel kleine stapjes. Maar zo simpel bleek het toch niet te zijn…

Drielagencargocult

Fri, 17 Jan 2025 08:23:02 +0100

Goede abstracties worden niet bedacht. Goede abstracties worden ontdekt. Ze vinden pas het levenslicht als reactie op een concrete vraag van de codebase. Softwareontwikkeling is in wezen een empirische aangelegenheid.

Waar zit de fout?

Fri, 22 Nov 2024 07:55:22 +0100

Mijn collega bracht een argument in dat vaak wordt genoemd als ik mensen vertel over testen via de voordeur: maar door de code direct aan te roepen, geven mijn tests onmiddellijk feedback over waar de fout zit. Als deze tests beginnen te falen, dan weet ik zeker dat daar de fout zit. En dat scheelt tijd in het debuggen van de code. – Maar dat laat de volgende vraag onverlet: is een unittest (waarbij “unit” wordt opgevat als “eenheid van code”) het beste middel om erachter te komen waar de fout zit?

De wet van Postel

Fri, 15 Nov 2024 08:09:28 +0100

Het is niet de verantwoordelijkheid van de aanroepende partij om de input van een functie te schiften opdat er valide waarden worden meegegeven. Een functie moet zo eerlijk mogelijk zijn in wat het accepteert – maar daar waar er speelruimte bestaat is het de verantwoordelijkheid van de functie zelf om de inputs te valideren.

Ik loste het op met een monad

Fri, 11 Oct 2024 08:34:29 +0200

Een soort van monad. Denk ik.

Bind, Map en Match

Fri, 27 Sep 2024 08:22:09 +0200

Ik schrijf al twee jaar op dit blog over functioneel programmeren in C#, dus je zou denken dat ik de basis inmiddels wel een beetje zou moeten beheersen – en toch overkomt het me nog regelmatig dat ik uitroep: och, zit het zo! Zo had ik onlangs – na een hoop gepiel (en een beetje hulp van Scott Wlaschin) – een openbaring met betrekking tot de Map- en Bind-functies.

Gedrag versus structuur

Fri, 13 Sep 2024 08:30:22 +0200

Een systeem dat niet precies doet wat het moet doen, maar wel eenvoudig aan te passen is, is meer waard dan een systeem dat precies doet wat het moet doen maar slechts met grote moeite gewijzigd kan worden. Want het gedrag van een systeem zal veranderen, hoe dan ook. De wereld verandert, en daarmee de wensen van onze gebruikers en stakeholders. Het is onze taak als softwareontwikkelaars om daarop voorbereid te zijn, en een systeem te ontwikkelen dat daarop voorbereid is.

Refactoring als communicatiemiddel

Fri, 30 Aug 2024 09:29:37 +0200

We refactoren niet alleen om het makkelijker te maken de code te wijzigen, we refactoren ook om de code zo helder mogelijk te laten communiceren. En code die helder communiceert is op zijn beurt weer makkelijker om te wijzigen.

Fragment (uit een discussie over AI coding assistants en privacy)

Fri, 09 Aug 2024 09:34:17 +0200

Hij, apodictisch: “Als we onze code delen met AI coding assistants, zodat zij daarop kunnen trainen, dan geven we onze concurrenten toegang tot onze code, en daarmee een marktvoordeel.” – Ik, grijnzend: “Ben ik heel cynisch als ik suggereer dat we onze concurrenten in dat geval misschien juist een nadeel bezorgen?”

Grote refactorslagen ondermijnen vertrouwen

Fri, 19 Jul 2024 07:55:35 +0200

Wat een stakeholder betreft is een grote refactorslag een enorme kostenpost zonder aantoonbaar resultaat. Een team dat erop staat niet verder te kunnen werken zonder eerst een hele tijd heel veel geld uit te geven – nota bene zonder daar iets voor terug te geven! –, ondermijnt het vertrouwen dat de stakeholder hen daarmee geeft.

Functioneel denken: een praktijkvoorbeeld

Fri, 31 May 2024 06:15:29 +0200

Onlangs hielp ik een collega een moeilijk volgbare berg code te reduceren tot enkele eenvoudig leesbare regels. Door onze oorspronkelijke, imperatieve redeneertrant van ons af te werpen, en deze te vervangen door een declaratieve stijl, reduceerden we het netelige origineel tot een elegante functionele oplossing. – Het was een schoolvoorbeeld van de kracht van functioneel denken.