Tag verantwoordelijkheid
Grote refactorslagen ondermijnen vertrouwen
Wat een stakeholder betreft is een grote refactorslag een enorme kostenpost zonder aantoonbaar resultaat. Een team dat erop staat niet verder te kunnen werken zonder eerst een hele tijd heel veel geld uit te geven – nota bene zonder daar iets voor terug te geven! –, ondermijnt het vertrouwen dat de stakeholder hen daarmee geeft.
Technieken vs trucjes
Een goede programmeur is een luie programmeur – dat is een bekende wijsheid in softwareontwikkelland. Want: een luie programmeur automatiseert oninteressante, repetitieve taken, en creëert op die manier de ruimte om zich bezig te houden met interessante, afwisselende taken. – Althans, dat is één opvatting van wat het betekent om een luie programmeur te zijn. Maar er zijn nog veel meer manieren om lui te zijn. Vandaag wil ik het hebben over zo’n andere manier. Vandaag wil ik het hebben over de wens, behoefte of neiging om een techniek te reduceren tot een trucje.
Waarom testen testers?
Tijdens een Retrospective gaf onze tester aan dat hij omkwam in het werk. Eigenlijk verbaasde niemand dat. Ons team bestaat uit vijf ontwikkelaars en één tester, en die ene tester is verantwoordelijk voor het schrijven van geautomatiseerde tests voor de code van al die vijf ontwikkelaars. Je kunt op je vingers natellen dat die situatie niet houdbaar is. – Dus wat te doen?
First time right?
Na afloop van mijn praatje kreeg ik de vraag of ik geloof in het idee van first time right. Mijn antwoord was: “Ik geloof niet dat er zoiets bestaat als first time right. Maar ik geloof wel in first time een stuk beter dan we het nu doen.” Tijd om dat antwoord verder uit te werken, was er op dat moment niet. Maar de vraag bleef wel in mijn achterhoofd spoken. Is het mogelijk om een systeem in één keer goed te bouwen?
Formuleer je kernwaarden
Hoe ziet softwareontwikkeling er – volgens jou – idealiter uit? Hoe functioneert een ontwikkelteam op de toppen van z’n kunnen? Wat is de verhouding tot hun stakeholders en collega’s? Hoe ondersteunt het management daarin? – Als je dat plaatje eenmaal scherp hebt, wat kun je dan concluderen over de kernwaarden van waaruit je software ontwikkelt?
Overpeinzingen (over vakmanschap)
“Ziet u niet hoe vaklieden, hoewel zij tot op zekere hoogte bereid zijn om hun opdrachtgever tegemoet te komen, zich niet kunnen veroorloven af te wijken van de voorschriften van hun vak? Is het niet verbazingwekkend en teleurstellend tegelijk dat bij een architect en een geneesheer de grondbeginselen van hun vak meer gerespecteerd worden dan bij de rede bij de doorsneemens, terwijl het juist de rede is die hij met de goden gemeen heeft?”
De tester als code reviewer
Mijn team heeft onze tester onlangs tot verplichte reviewer gemaakt voor elk pull request (PR). Hij heeft een heel specifieke opdracht – drie, eigenlijk: 1. Ga na of het PR unit- of integratietests bevat. Zo nee, keur het PR dan af. 2. Ga na of je de unit- en/of integratietests kunt begrijpen. Zo nee, keur het PR dan af. 3. Ga op basis van de unit- en/of integratietests na of de code werkt zoals bedoeld. Zo nee, keur het PR dan af. Pas als aan alle drie voorwaarden is voldaan, is het PR klaar om naar de main branch te mergen.
Iteratief verbeteren in de praktijk
Er was een briefje op de deur geplakt, de deur richting de wc’s: “Dicht houden in verband met de kou!” Er was een dingetje dat je moest weten. Als die deur eenmaal dicht was, dan kon je de afdeling softwareontwikkeling alleen nog maar uit – niet meer in. Een slimme ontwikkelaar liet die deur dus op een kier staan. En we waren allemaal slimme ontwikkelaars – misschien was het daarom wel zo koud, bedenk ik nu.
Het is niet jouw verantwoordelijkheid een onmogelijke deadline te halen
Er gebeurt iets wonderlijks wanneer je tegen een ontwikkelteam zegt dat die en die feature een deadline heeft: ze gaan hun best doen om die deadline te halen. Dat is een nobel streven, natuurlijk. Maar het is ook een gevaarlijk gegeven. Want niet elke deadline voor elke feature is even realistisch. Een team dat, ongeacht de haalbaarheid, gaat rennen om die deadline te halen, werkt zichzelf – en haar stakeholders – in de nesten.
Waar doe je het voor?
Een luie programmeur grijpt alles aan om zijn eigen werk makkelijker te maken (met uitzondering van het besparen op kwaliteit - daar is een andere term voor: een slechte programmeur). En makkelijker maken betekent meestal: automatiseren. Want waarom zou je zelf het werk doen, als een machine het ook voor je kan doen?