Meten is weten! 📈 Het aantal producten waar ik aan mee heb mogen werken is inmiddels vrij groot.🏅 Maar het aantal projecten hiervan met zichtbare sturing op de directe doelstellingen is helaas bedroevend laag. 🤔 En nee, ik bedoel hiermee niet nutteloze metrieken als”velocity” 🚲 of afgewerkte user stories 🗑️. Ik heb het over concreet […]
In een recent project vroeg een directeur 🎩 me in de context van een project met tijdsdruk de bevestiging dat ik “hopelijk niet uit een industrie kom waar alles aan strenge kwaliteitsnormen moet voldoen”. Een goede vraag! 🎯 Het roept namelijk iets fundamenteels op over softwareontwikkeling: is er ruimte voor snelheid zonder in te boeten op kwaliteit?
(En de “Hexagonal” architectuur dus ook.) Nadat Uncle Bob (Robert Martin) jaren geleden zijn “Clean Architecture” in een vaag artikel op zijn blog beschreef, heb ik deze architectuur in verschillende Java backend projecten met wisselend succes toegepast. In eerste instantie door mijn onbegrip over zijn suggesties 🤷♂️, maar later ook door onbegrip over wat het
De meeste programmeurs blijven een voorkeur hebben voor het achteraf schrijven van automatische testen. Ik vind dat sub-optimaal, maar het is beter dan geen testen. Met de opkomst van code assistenten, is de nieuwste trend om deze testen door AI te laten schrijven. ✨ Maar is dat wel zo’n goed idee? 🤔 Voor eenvoudige code
En de goedkoopste ook! 💰 Voor de recente ontwikkeling van mijn “Cannect” app had ik een backend nodig die kandidaten ter beoordeling voorstelt, en beschikbare kandidaten aan elkaar koppelt. Dit is een relatief eenvoudig algoritme, maar wel met potentieel veel data die bovendien doorlopend wijzigt. Omdat mijn doel was om de backend zo goedkoop mogelijk
💡 Wat als ik alleen nog testen schrijf, en rest over laat aan AI? Ik probeer al jaren netjes volgens TDD te werken: Ik schrijf eerst een (falende) test, schrijf daarna slechts voldoende code om de test te laten slagen, en optimaliseer regelmatig de resulterende code. Zo codeer ik richting het langzaam evoluerende ontwerp dat
Veel ontwikkelaars denken bij Free Open Source Software nog steeds aan iets wat je gratis kunt gebruiken. Maar “Free” gaat in deze context niet over de prijs, maar over vrijheid. Vrijheid om de software aan te passen, te delen en te verbeteren. En hoewel Open Source Software vaak zonder kosten beschikbaar is, betekent dat niet dat er geen
Krijgen ze nog de kans om ervaring op te doen? In de afgelopen decennia is de vraag naar software gigantisch gestegen. Dit heeft geleid tot een steeds schevere verhouding tussen het aantal nieuwe en de inmiddels heel kleine groep (zeer) ervaren softwareontwikkelaars. Nu komt AI om de hoek kijken: Tools zoals GitHub Copilot en Cursor
In softwareontwikkeling kan het verleidelijk zijn om te wachten tot een product “perfect” is voordat je het lanceert. Maar in plaats van te streven naar één grote lancering, kan het uitbrengen van kleinere, iteratieve en incrementele updates veel voordelen opleveren. Hier zijn drie redenen waarom kleine releases de betere aanpak zijn: 1️⃣ Snellere feedback: Door
Waarom het afsnijden van bochten bij ontwikkeling van software geen verstandige keuze is. In de wereld van softwareontwikkeling blijft het verleidelijk om snelle oplossingen te kiezen of stappen over te slaan om tijd te besparen. Maar, hoe verleidelijk het ook kan zijn om bochten af te snijden, deze efficiëntie brengt vaak meer schade dan voordeel
