Tip: log uit
Ik heb een soort van ochtendritueeltje als ik mijn laptop aan het begin van de dag opstart. Ik check mijn mail, mijn Facebook, LinkedIn, bekijk de bezoekersaantallen van deze website - en open dan Microsoft Teams om te zien wat ik allemaal gemist heb sinds gisteren. Het is een kwartiertje opstarttijd, een soort-van-rust-momentje voordat ik aan de dagelijkse arbeid begin. Sinds kort voeg ik daar een extra handeling aan toe: ik log uit.
Leren in je codebase
Laatst had ik een gesprek met een collega van me, over een meningsverschil dat hij had met onze leidinggevende over zijn zelfstudieproject. Hij wilde zijn handen vuil maken - dat is hoe hij het liefst leert -, niet in een klein, losstaand codeproject, maar in een branch van onze productiecodebase. Onze leidinggevende vond dat, tot frustratie van mijn collega, een slecht idee. - Daar was ik het, eerlijk gezegd, wel mee eens.
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?
Nóg een reden om testgedreven te ontwikkelen
Als je mij zou vragen: waarom zou je testgedreven ontwikkelen? dan zou ik zeggen: zodat je tests hebt. Maar in The Art of Agile Development van James Shore vond ik een andere reden. Test-Driven Development dwingt je na te denken hoe het is een stuk code te gebruiken, in plaats van het te implementeren. Het vraagt je om helder te krijgen: hoe kan ik deze functionaliteit zo goed mogelijk ontsluiten, in plaats van: hoe kan ik deze functionalteit zo goed mogelijk bouwen?
Refactoren na Tolstoj
Laatst las ik een verhaal van Lev Tolstoj genaamd Uit de aantekeningen van vorst D. Nechljoedov. Luzern (1857), een verhaal gebaseerd op zijn ervaringen tijdens een reis door Zwitserland. Het is geschreven in dagboekvorm en gaat over een Russische vorst die een nacht verblijft in het Schweizerhof, een prachtig chique hotel in Luzern, Zwitserland. Mij deed het aan refactoren denken. - Ja sorry: beroepsdeformatie!
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.
Al doende deuren openen
Coachen is niet alleen praten. Coachingsgesprekken zijn ingebed in een context van (professionele of persoonlijke) situaties en handelingen. Zo’n gesprek eindigt dan ook niet wanneer de betrokkenen ophouden te praten. Dat wat besproken is, blijft - hopelijk! - in het hoofd van de coachee rondzingen. Zo vindt het zijn uitwerking in een nieuw perspectief op de situaties waarin deze terechtkomt, en misschien zelfs wel in nieuwe handelingen. Maar je hoeft als coach niet te alleen hopen dat dit gebeurt, er bestaat een manier om de coachee een handje te helpen. Dat doe je door middel van opdrachten.
De ontwikkelaar als chirurg
Working Effectively with Legacy Code van Michael Feathers staat vol met adviezen waar je cleancodershart een slag van overslaat. Vrijelijk raadt Feathers je aan encapsulatie uit het raam te smijten of onhandelbare methods zomaar tot class te promoveren. Zijn inzichten gaan lijnrecht in tegen alle richtlijnen om goede, onderhoudbare code te schrijven. Het boek is zonder twijfel een aanrader voor elke softwareontwikkelaar.
Wat je aanpakt weegt licht
De vloek van een goed functionerend team is dat de organisatie daarvan vindt: die kunnen dit en dat best erbij hebben. De zegening van een goed team is dat de organisatie daarin meestal wel een punt heeft. Dat gezegd hebbende, mijn team was niet blij toen we de opdracht in onze mik geschoven kregen om een bedrijfskritische legacy applicatie door te lichten. We hebben ons werk voor die applicatie lange tijd zo ver mogelijk naar achteren geschoven. Maar enkele Sprints terug was het dan toch zo ver. En eerlijk gezegd: het viel alleszins mee.
De standaard versus de business
Onze business volgt de QTI-standaard, maar ze gebruiken niet alles. Zo bestaat er - op dit moment - nog geen behoefte om Items te construeren die uit meerdere rijen bestaan. Bij het modelleren van ons domein werden we voor een keus gesteld: volgen we de QTI-standaard bij het uitschrijven van ons model? Of leggen we alleen vast wat de business nodig heeft, en laten we ons eigen model daarmee afwijken van de standaard? Concreet: ondersteunen we meerdere rijen of niet?