🤔 De constructie van het resultaat (= het “bouwen”) wordt bij software al vele jaren uitgevoerd door computers. Er gaat een gedetailleerde specificatie als broncode in, en er komt een uitvoerbaar programma uit.
💡Wordt het niet eens tijd om te beseffen dat mechanisch projectmanagement dat voor het bouwproces is ontwikkeld niet zo goed werkt voor het creatieve ontwerpproces dat er aan vooraf gaat?
Het kijken van de Clean Coders videos van Robert Martin (aka Uncle Bob) heeft mij meer dan 10 jaar geleden nieuwsgierig gemaakt naar “Test Driven Development”. Dit heeft mijn manier van programmeren, ontwerpen en testen van software destijds volledig op zijn kop gezet. 🚀
Het was daarom fascinerend om Kent Beck als bedenker van TDD onlangs tijdens de “Tech Excellence Conference 2024” zowel de ontstaansgeschiedenis als onderliggende filosofie nogmaals te horen vertellen.
➡️ Ik denk dat zijn verhaal voor iedere software ontwikkelaar verplichte kost zou moeten zijn. Dit is dus een mooi moment om je te laten inspireren:
💡 Stop met raden en het zelf invullen van de antwoorden
Laatst las ik een parabel over een bar voor die ineens een stroom nieuwe klanten verwelkomt. De eigenaar van de bar is overtuigd dat zijn uitgebreide wijnassortiment de reden is, maar in werkelijkheid zijn de nieuwe klanten een vriendengroep die er per ongeluk terecht kwamen. 🤦
Veel bedrijven maken dezelfde fout: ze bouwen voort op aannames zonder de echte drijfveren van hun klanten te begrijpen. Ze geloven in hun eigen verhaal en missen de kans om waardevolle inzichten te verzamelen.
➡️ De les? Vraag je klanten waarom ze kiezen voor jouw product of dienst. Vraag je gebruikers wat hen aantrekt, wat hen vasthoudt – en luister écht.
Want pas als je stopt met raden, kun je beginnen met groeien. 💸
Snelheid in softwareontwikkeling is het hoogste goed. Zodra het werkt zijn we klaar. Maar deze snelheid heeft een prijs: De verleiding om code te kopiëren en te plakken wint het vaak van de moed om de code naar de nieuwe inzichten te refactoren. 🛠️
Elke nieuwe functionaliteit leert ons iets nieuws over de structuur die onze code nodig heeft. Toch ontbreekt vaak het inzicht – of de tijd – om deze lessen toe te passen en de fundering te versterken. Het resultaat? Code die juist steeds moeilijker te onderhouden en uit te breiden is. ⛈️
➡️ Waarom zien we refactoren nog steeds als een luxe in plaats van een noodzaak? Duurzame software vereist niet alleen snelheid, maar ook de moed om te vertragen en te verbeteren.
Mijn oproep: Laten we vaker stilstaan bij de kwaliteit van onze code. Gebruik elke nieuwe feature als een kans om niet alleen het product, maar ook de code zelf beter te maken. 🌈
Na het goud op de Olympische Spelen boekte Worthy de Jong onlangs opnieuw een gouden succes in het 3×3 basketbal tijdens de World Tour in Hong Kong. Zijn rol en hieruit volgende succes deed mij denken aan een bijzondere 3×3 basketbal regel: Er is tijdens de wedstrijd geen coach toegestaan. Deze regel maakt het team dus volledig zelfsturend.
Ik vind dit een fascinerende parallel met Scrum teams. Sterker nog, een speler als Worthy vervult in zijn teams de rol van de Scrum Master zoals die echt bedoeld is: Iemand die het team helpt presteren boven het niveau van de som van de individuen, terwijl hij zelf onderdeel is van de prestatie.
Bedenk eens hoe onlogisch het is om een externe Scrum Master in te huren die na een korte training een diploma heeft gehaald, en vervolgens de werkelijke experts vanaf de zijkant gaat vertellen hoe ze hun werk moeten doen. 📣
Mijn suggestie is om in plaats hiervan een “Worthy” inhuren, zodat niet alleen het team beter functioneert maar ook de winnende driepunter wordt gescoord! 🏆