Verandering on dotkarl

Conservatieve verandering

Fri, 29 May 2026 07:30:24 +0200

Hoe weet je of je het goed doet? Dat het niet beter kan? Ik ben van mening dat het onze professionele plicht is om van tijd tot tijd onze manieren van werken om te gooien. Omdat ik denk dat er betere manieren zijn, maar ook en vooral omdat we niet weten of de huidige manier van werken de beste is, als we deze niet regelmatig in vraag stellen. – Maar dan: de anderen.

Worsteling

Fri, 08 May 2026 07:51:41 +0200

We betoogden tegen verschillende omgevingen voor ontwikkel, test, acceptatie en productie: dat is duur en bovendien nodeloos complex. Er is maar één omgeving die ertoe doet: productie. Maar om de wijzigingen naar productie klein en veilig te houden, kunnen we functionaliteit verbergen. – “Dat is valsspelen!” riep iemand in het publiek, de wanhoop nabij. “Je hebt nu alsnog een testomgeving, alleen dan op productie!”

Veranderen doet pijn

Fri, 09 Jan 2026 08:24:21 +0100

Er gebeurde iets interessants, onlangs tijdens een bijeenkomst van het strategietraject waar ik mezelf volledig uit vrije wil mee heb opgezadeld. We werden gewezen op een deadline – en schoten in een kramp. Onze eerste reactie was: “Dat is te vroeg, het is nog niet af!”

Hoe heb je het volgehouden?

Fri, 17 Oct 2025 08:53:32 +0200

Software ontwikkelen is niet makkelijk, het is van zichzelf al niet makkelijk en het wordt nog moeilijker omdat je met mensen werkt en mensen zijn nooit makkelijk.

Over de boekenclub

Fri, 28 Feb 2025 08:18:56 +0100

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?

Fri, 14 Feb 2025 08:30:39 +0100

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)

Fri, 07 Feb 2025 08:29:45 +0100

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

Fri, 24 Jan 2025 08:20:25 +0100

“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?

Fri, 20 Dec 2024 08:28:02 +0100

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

Mon, 20 Jun 2022 08:43:45 +0200

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?

Mon, 30 May 2022 08:59:07 +0200

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

Fri, 01 Apr 2022 08:06:10 +0200

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

Fri, 07 Jan 2022 08:18:00 +0100

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

Mon, 20 Dec 2021 11:12:12 +0100

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.

Klimmen op de cultuurladder

Fri, 26 Nov 2021 08:04:29 +0100

Het succes van een organisatie is van een boel dingen afhankelijk. Eén van die dingen is de bedrijfscultuur. Een organisatie waarin hard werken de norm is, en het vanzelfsprekend is dat je als team staat voor je resultaten, zal beter presteren dan een cultuur waarin medewerkers doen wat er van hen gevraagd wordt en geen millimeter meer. Dus: hoe krijg je het voor elkaar om de juiste cultuur te kweken in je organisatie? Dat is de vraag die centraal staat in De Cultuurladder van Marcel van Wiggen, Gerard Vriens en Frits Galle.

Anderen veranderen met hun eigen argumenten

Fri, 05 Nov 2021 07:06:59 +0100

Alle verandering is moeilijk, maar anderen veranderen, dat is nog veel moeilijker. Toch zijn we vaak van anderen afhankelijk om te kunnen veranderen, bijvoorbeeld als je je collega’s aan wil sporen een nieuwe werkwijze uit te proberen. Of wanneer je als manager de opdracht hebt gekregen om een afdeling te reorganiseren. Er zijn boeken volgeschreven over verandermanagement op de werkvloer, Verandergedrag van organisatiepsycholoog en communicatiekundige Thijs Leenman is daar slechts één van.