Tag procesverbetering
Efficiënter overleg dankzij Loop-componenten
Hé jij. Ja, jij. Gebruik je Microsoft Teams voor het gros van de communicatie op je werk? Ja? - Open dan eens een chat met iemand, een collega waar je vaak nauw mee samenwerkt. Onderaan, onder die balk waar je je bericht in tikt, daar zie je een icoontje staan - tussen die van de bijlagen en de emoticons in. - Zie je ’m? Hij lijkt een beetje op een mislukt apenstaartje. Dat is nou het icoon om een Loop-component in die chat te smijten.
Hoe hersenwetenschap programmeurs kan helpen
Er is in de vakliteratuur over softwareontwikkeling geen gebrek aan gepeperde meningen over hoe goede code eruit dient te zien. Goede code is naar hun mening eenvoudig, bijvoorbeeld, of testbaar of uitbreidbaar. Je zou kunnen zeggen dat hun redenen erop geënt zijn software zo goed mogelijk te kunnen onderhouden. Wie dat zou moeten doen en hoe ze dat aan moeten pakken, daar zijn de meningen minder gepeperd over. Veel professionals lijken code te beschouwen als iets wat op zichzelf staat, zonder veel oog te hebben voor de programmeurs die dat onderhoud zouden moeten plegen. Dat geldt niet voor Felienne Hermans. In The Programmer’s Brain behandelt ze vragen als: wat gebeurt er in het brein als je code leest? Hoe leer je zo efficiënt mogelijk nieuwe programmeertalen en -concepten? En hoe kun je deze kennis inzetten om betere code te schrijven?
Gedachten naar aanleiding van een PI-planning
Ik had onlangs het geluk aanwezig te mogen zijn bij een Program Increment-planning - kortweg: PI-planning. Het was de tweede die mijn werkgever ooit organiseerde, en de eerste waar ontwikkelaars bij aanschoven. Het was een hele ervaring. En ik zal in wat volgt kort reflecteren op die ervaring.
Incidentanalyse zonder schuldigen
Wat doet jouw team na een productieverstoring? En wat doet jouw team als een eindgebruiker een bug meldt? - Wat bij een grote bug? Wat bij een kleine? Neem je het ter kennisgeving aan, en ga je op dezelfde weg door? Ga je met vingers wijzen en mensen uitfoeteren voor hun nalatigheid? Of kijk je naar manieren waarop je de productieverstoring of bug in de toekomst kunt voorkomen? En waar kijk je dan naar - naar het individu, of het systeem?
Tevreden ontwikkelaars én stakeholders dankzij speelruimte
Dit is denk ik voor veel teams een herkenbare situatie: de ene Sprint verbranden jullie achttien effort points, de volgende twintig, de keer daarop vijftien. Wat is dan de capaciteit van het team? Hoe kun je voorspellen wat jullie de volgende Sprint gaan opleveren, als de capaciteit fluctueert van keer tot keer? Het antwoord is: dat kun je niet. Maar in The Art of Agile Development van James Shore vond ik hier een oplossing voor.
De blog die ik nooit schreef
Op 23 augustus maakte ik uitgebreide aantekeningen voor een blog - en in de maanden daarna deed ik mijn uiterste best die aantekeningen vooral niet uit te werken. Sindsdien vervuilt deze pseudoblog de broncode van deze website eigenlijk alleen maar. Ik zou ’m natuurlijk weg kunnen gooien, maar aan de andere kant: ik zou het ook niet kunnen doen. Dit is een deconstructie van de blog die ik nooit schreef.
Hoe Nooglers testen de norm maakten
Google greep haar snelle groei aan als kans. In plaats van zich te focussen op hun bestaande werknemersbestand, richtte het management ze zich op nieuwe medewerkers. Ze gaven deze nieuwe Googlers, liefkozend Nooglers genoemd, bij binnenkomst allemaal hetzelfde praatje over testen en het belang ervan. Ze gebruikten de Nooglers, buiten hun weten om, als Trojaans paard om een cultuurwijziging te bewerkstelligen.
Is onze performancetest mislukt?
Het doel van de performancetest was niet om aan te tonen dat onze applicatie de load aankon. Het doel was om erachter te komen of onze applicatie de load aankon. Nu weten we het antwoord: nee. Men zegt niet voor niets: meten is weten, en niet: meten is slagen.
Evolutionaire datamigratie met FluentMigrator
In het kort komt evolutionair databasedesign hier op neer. Stel, een ontwikkelaar maakt een wijziging in de code die een databasewijziging impliceert. In dat geval is het aan dezelfde ontwikkelaar om een migratiescript te schrijven die de codewijziging mogelijk maakt, en deze bij de codewijziging in te checken. De databasewijziging is onderdeel van de codewijziging, als het ware. En terecht, want zonder de databasewijziging is het niet mogelijk om de gewijzigde code te runnen.
Iteratieve verfijning
Dat software ontwikkelen - vandaag de dag in elk geval - een iteratief proces is, is een plattitude. Dat ook de voorbereidingswerkzaamheden van programmeren iteratief kunnen (of moeten?) worden vormgegeven, is iets wat ik misschien wel wist, maar me nooit helemaal beseft heb. Het interessante van Scrum (en van softwareontwikkeling in het algemeen) is dat je het jarenlang kunt doen, en toch steeds opnieuw best en better practices kunt ontdekken - of herontdekken.