Tag verandering
Over de boekenclub
Voor de vuist weg heb ik eens geroepen: “We zouden eigenlijk elke nieuwe werknemer een boek mee moeten geven als ‘ie begint. Met als (impliciete?) boodschap: we verwachten dat je dit leest. We verwachten dat je tijd vrijmaakt voor zelfstudie.” – Erop terugkijkend, was dat het prille begin van de boekenclub die ik maanden later oprichtte.
Wat houdt ons tegen continu te leveren?
CI/CD houdt meer in dan het alleen inrichten van een buildserver: het is een heel andere manier van werken. Het verlangt van je dat je je werkt anders opdeelt, dat je in kleine stapjes werkt, dat alle code die je schrijft continu van hoge kwaliteit is. Continuous delivery vraagt van ontwikkelaars bepaalde gewoontes – gewoontes waar ze zich goed bij voelen – te herzien.
Softwareontwikkeling is een popcultuur (maar hoeft dat niet te zijn)
Het Agile manifest belooft betere manieren van softwareontwikkeling mogelijk te maken door de nadruk te leggen op “individuals and interactions” boven “processes and tools”. Maar wat is Agile ontwikkeling verworden, ruim twintig jaar na het schrijven van dat manifest? – Scrum + Jira. Oftewel: een process en een tool.
Teveel tegelijk
“We zijn met teveel dingen tegelijk bezig,” constateert een ontwikkelaar tijdens de Retrospective. Die is met dit bezig, die met dat; hij met zus en zij met zo. Er is geen eenheid, iedereen werkt op zijn eigen eiland. – Het is een terugkerend thema. Waar ligt dat aan?
Is TDD alleen nuttig als iedereen het doet?
Het is geen geheim dat ik een liefhebber ben van Test-Driven Development. Ik schrijf er regelmatig over op dit blog, probeer mijn collega’s de kneepjes van de praktijk eigen te maken, en laat het onderwerp graag ter sprake komen wanneer ik vakgenoten spreek op gebruikersgroepen of conferenties. – Vaak krijg ik de repliek: “Allemaal leuk en wel, dat TDD, maar dat heeft eigenlijk alleen maar zin als iedereen in het team het doet.” Daarmee implicerend: en dat is waarom ik het niet doe.
Het probleem met technische schuld op je backlog
Zo gaat mijn team om met het monitoren van technische schuld: we prikken elke Sprint een moment waarop we er met elkaar over praten, en als we het belangrijk genoeg vinden om er wat aan te doen, dan voeren we een Product Backlog Item op om die schuld weg te werken. Die aanpak werkt goed - goed genoeg, in elk geval. De technische schuld van onze huidige applicatie blijft grotendeels binnen de perken. En bovendien - dat is nog veel belangrijker - is iedereen in het team op de hoogte van het feit dat sommige plekken verbetering behoeven, en welke plekken dat zijn. Maar toch zit iets me niet helemaal lekker in die aanpak.
Wat is de O in SOLID nog waard?
Een ontwikkelaar die eens code schrijft en deze nooit meer aan denkt te hoeven passen, is een ontwikkelaar die rot in zijn applicatie verwelkomt. Een al te strikte naleving van het Open-closed principe (OCP) getuigt van een ronduit onverantwoorde houding - in elk geval binnen de context van Agile ontwikkeling. Waar komt de aantrekkingskracht van het OCP dan vandaan?
Eén test per keer
Ik hou niet van programmeerboeken die van me vragen dat ik onder het lezen code schrijf. Daar kan zo’n boek niks aan doen, ik houd er nu eenmaal van om een boekje op de bank te lezen, ver weg van mijn laptop. Voor één boek maak ik een uitzondering, en dat is Learning Test-Driven Development van Saleem Siddiqui. Dat boek draait namelijk niet om het eindproduct, de code. Het draait om het proces.
Over het hek van Chesterton
Ik ben niet vies van het refactoren van code die ik onduidelijk vind, of zelfs van weggooien van (meestal dode) code. Dat is een goede eigenschap wanneer je het met beleid doet en een slechte als het uit louter enthousiasme voorkomt. De eerste resulteert in helderder en eenvoudiger code, de tweede in buggy software. Waar zit hem precies het onderscheid in? Het antwoord vond ik in Software Engineering at Google in het hoofdstuk over kennisdeling.
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.