Wat is een monad?
Wat is een monad, vraag je? Simpel: monaden zijn de meest fundamentele zijnden in het universum - ondeelbaar, onafhankelijk, zowel geestelijk als lichamelijk - de bouwblokken van de werkelijkheid, die tezamen een door God geschapen harmonieus geheel vormen - overigens zonder elkaar te beïnvloeden; het zijn perfect op elkaar afgestemde atomen die in autonoom opereren maar in hun zijn het voltallige universum spiegelen. Althans, dat is wat Gottfried Wilhelm Leibniz onder “monaden” verstond. Maar dit is nu eenmaal een blog over softwareontwikkeling, dus je zal wel dat functionele spul bedoelen.
Test third party code
Het updaten van third party code is net zozeer een risicovolle onderneming als het niet updaten ervan. In beide gevallen loop je kans op de introductie van bugs. Er is een uitweg uit dat probleem. En die uitweg is - zoals meestal in softwareontwikkeling - testen, testen, testen.
Van rader in het geheel naar bron van talent
Hoe ziet een bedrijf haar personeel? Een hint van een antwoord zit ‘m in de daaraan toegewijde afdeling: human resource management. Personeel is een resource, een hulpbron - net als het IT-systeem, maar dan menselijk - die gemanaged moet worden. Die metafoor heeft enkele interessante consequenties, die inderdaad regelmatig haar uitwerking vinden in de praktijk: medewerkers zijn raderen in het geheel, ze moeten op hun prestaties beoordeeld worden en kunnen eenvoudig vervangen worden wanneer ze een negatieve impact hebben op dat geheel. Die zienswijze is hopeloos achterhaald, betoogt Rob van den Berg in Futureproof talentmanagement.
Hoe ziet een leercultuur eruit?
Mijn zelfstudietijd - dat is de tijd waarin ik mijn ervaringen over softwareontwikkeling uitwerk in blogs als deze - is mij heilig. De afgelopen jaren heb ik gemerkt dat als je structureel de tijd neemt om je kennis te verbreden en te verdiepen (en te documenteren!), dit zich met rente terugbetaalt in je productiviteit als ontwikkelaar. Dat inzicht is een cadeau dat ik mijn collega’s van harte gun. Nieuwe dingen leren en - net zo belangrijk! - die kennis met je collega’s delen is iets wat helaas nog veel te weinig gebeurt op onze afdeling.
Een presentje voor presenters
Lieve collega’s, bedankt voor alle toffe presentaties die jullie (met een beetje druk van mijn kant) hebben willen verzorgen het afgelopen jaar, ik kan niet in woorden uitdrukken hoe zeer ik jullie waardeer! Ik hoop dat dit wijntje iets van die dankbaarheid over kan brengen. De volgende keer zal die blijk van waarderig een stuk minder lang op zich laten wachten, beloofd!
Test het systeem, niet de class
Het is belangrijk om vast te stellen dat er een bug in het systeem was geslopen, ondanks dat de functionaliteit die de bug veroorzaakte ogenschijnlijk gedekt was door tests. Waarom “ogenschijnlijk”? De class die de serialisatie voor zijn rekening nam, werd wel getest, maar alleen in isolatie en niet in de context van het systeem. - Vraag je af wat de implicatie daarvan is. Het betekent dat onze tests bewezen dat een class naar behoren werkt. Of het systeem als geheel naar behoren werkt, dat kunnen we op basis van de tests niet concluderen. Terwijl dat juist is waar het om gaat!
Nog zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Vandaag pen ik kort neer welke inzichten ik de tweede dag opdeed.
Wat is een unit?
Een tijd geleden presenteerde ik enkele ideeën over testen aan mijn collega’s. Toen ik aankwam bij het gedeelte waarin ik stelde je het best via de voordeur kunt testen, stelde een collega apodictisch: “Een unittest test een openbare method op een class. Elke afhankelijkheid op die class moet je mocken.” Dat is een manier om er naar te kijken, zeker. Het is de zogenaamde mockist strategie, ook wel bekend als de Londense school van unittesten. De vraag waar ik me op wil richten is: waar komt de aantrekkingskracht van deze strategie dan vandaan? Ik geloof dat deze voortkomt een bepaalde interpretatie van wat een unittest is of moet zijn. Meer specifiek: wat de unit in unittest is of moet zijn.
Zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Ik hoorde een boel nieuwe ideeën, werd gesterkt in enkele van mijn al bestaande overtuigingen, en uitgedaagd sommige ingesleten gewoonten te herzien. Uit mijn stapel aantekeningen destilleer ik zes inzichten die ik alleen al de eerste dag opdeed.
Waarom zijn zoveel programmeurs bètanerds?
Als filosoof kan ik een titel als How do our ideas about coding affect the software we create? natuurlijk moeilijk weerstaan - en ik heb dan ook met veel plezier naar het gelijknamige praatje van Christin Gorman gekeken. Gorman begint vanuit een probleem: de softwareontwikkelpopulatie (3x woordwaarde) is weinig divers. Ze bestaat, gechargeerd gezegd, voor het grootste gedeelte uit nerds met interesses in de hoek van de bètawetenschappen. Hoe komt dat?