Tag communicatie
Waarom DRY? Waarom DAMP?
Productiecode optimaliseer je voor onderhoudbaarheid; testcode voor leesbaarheid. Waarom? Omdat de context van productiecode en testcode verschilt. Beide dienen een ander doel, wat verschillende eisen aan de code stelt. Ze opereren in verschillende sferen, zogezegd.
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.
Tests zijn specs
Kleine (of liever: te kleine) tests geven weinig informatie over de werking van het systeem. Ze verlangen van de lezer om op de hoogte te zijn van implementatiedetails, en verliezen zo het grote geheel uit het zicht. Voor grotere unittests gaat die beperking niet op. Zulke tests doen geen aannames over de interne werking van het systeem. Ze beschrijven slechts de buitenkant ervan: wat de gebruiker - hoe we die dan ook mogen definiëren - invoert en wat deze terugkrijgt. Het gevolg daarvan is dat je tests leesbaar worden voor niet-ontwikkelaars.
In godsnaam, neem de tijd om je Sprint Review voor te bereiden
Een Sprint Review is geen one man show. (Al wordt het - terecht - “het feestje van de Product Owner” genoemd.) Een Sprint Review is geen PowerPoint-presentatie. (Al kan en mag er gerust PowerPoint gebruikt worden tijdens de Sprint Review.) Een Sprint Review is geen demo van de nieuwste functionaliteit. (Al wordt de nieuwste functionaliteit wel gedemonstreerd.) Een Sprint Review is een teamprestatie - maar niet alleen het team is aan het woord. Een Sprint Review is een gesprek - en in een gesprek vindt altijd plaats tussen meer mensen.
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!
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.
Collegiale documentatie
Ik ken geen enkele ontwikkelaar die het leuk vindt om documentatie te schrijven - ik ook niet - en dat is omdat goede documentatie schrijven moeilijk is. Het is moeilijk, omdat je je vanuit een positie van iemand die snapt hoe iets werkt, je in moet leven in iemand die dat begrip nog niet heeft. Mijn belofte “even” documentatie te schrijven werd daarom al gauw “een uur” documentatie schrijven. Maar het resultaat is volgens mij wel de moeite waard, dus laten we er even (…een uur?) naar kijken.
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.
De Standup is geen statusmeeting
In The Art of Agile Development van James Shore kwam ik een zinsnede tegen die me deed opveren: de Daily Standup (ook wel Daily Scrum genoemd) is geen statusmeeting. - Laten we kijken wat dat betekent.
Eindgebruikers horen
De snelste weg naar tevreden gebruikers, is door goede software te bouwen die doet wat het moet doen. Dat klinkt makkelijk en dat is het niet. Waarom niet? Omdat software bouwen niet een kwestie van bouwen alleen is. Als dat zo zou zijn, dan zou de beste softwareontwikkelaar een mensenschuwe programmeur zijn, iemand die je het best met rust kunt laten, terwijl ‘ie als een razende specificaties omzet in code.