Tag boeken
Mijn eerste code review
De tijd maakt alles kapot – maar nu ben ik nog jong genoeg om me mijn eerste code review te herinneren. Althans, ik herinner me een gevoel – want de inhoud van het pull request ben ik natuurlijk allang kwijt. Het gevoel laat zich denk ik het best omschrijven als een vorm van hulpeloosheid – gevolgd door ongemak.
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?”
Deze blog bevat tooltips
Je hebt van die dagen, dan blog je al ruim twee jaar en dan pas ontdek je dat Markdown tooltips ondersteunt.
Leiden zonder romantiek
Wat maakt een goede leider? Daar zijn bibliotheken over volgeschreven. Leiders zijn aanvoerders: moedig gaan ze voor de troepen uit. Ze maken groei mogelijk. Verheven zijn ze, een voorbeeld voor de rest. Maar ze zijn ook je maatje. Vaak bedienen we ons van dit soort romantische beelden als we het over leiders hebben. De praktijk, merkt veranderkundige Joost Kampen op in Destructief leiderschap, is vaak weerbarstiger.
Waarom ik die method dupliceer
Een collega keek over mijn schouder mee. Ik was zojuist bezig met een bugfix, dus ik schreef een test, zag ’m falen en navigeerde naar de plek waar ik mijn aanpassing meende te moeten doen. Ik hernoemde de method, plakte er de suffix _old achteraan. Daarna dupliceerde ik het geval, en bracht mijn wijziging aan in het duplicaat. Mijn collega vroeg me: “Wacht, waarom doe je dat?” Nou…
Beter testen in de Agile praktijk
Een twee weken durende Sprint is te kort voor het opstellen van gedetailleerde testplannen, en wie de testwerkzaamheden bewaart voor de laatste fase van de Sprint, komt onvermijdelijk in tijdnood. Hoe kan het beter? Dat antwoord wordt gegeven aan de hand van twintig praktijkcases in De karakteristieken van een modern testproces.
Leren leren op het werk
De mens is een lerend wezen. Wie zijn ogen ervoor openhoudt, ziet dat we haast elke dag wel een nieuw inzicht opdoen. Maar zodra men aan het werk gaat, lijkt een groot deel van de mensen die lerende houding thuis te laten. Sterker nog, goedbedoelde leerinitiatieven worden van tijd tot tijd zelfs met vijandigheid begroet. Waarom? Zijn we toch niet zo lerend als je op voorhand zou denken?
De vraag achter de vraag ontdekken
Requirements engineering is… moeilijk. Heel moeilijk. Het achterhalen van de systeemvereisten vraagt een enorme inspanning van requirementsanalisten. Het op te lossen probleem is immers altijd vager, minder gedefinieerd dan de absolute precisie die software verlangt. Analisten moeten belanghebbenden de juiste vragen weten te stellen om een vertaalslag te kunnen maken van business naar IT. Gelukkig hoeven ze dat niet alleen te doen. Handboek requirements van Nicole de Swart is een onmisbare gids in dit proces.
Aantekeningen over requirements - deel 2
Het opstellen van de juiste requirements is één van de moeilijkste onderdelen van softwareontwikkeling. In een eerdere blog beschreef ik de eerste acht lessen die Karl Wiegers of dit onderwerp formuleerde in Software Development Pearls. In deze blog volgen de tweede acht.
Aantekeningen over requirements - deel 1
Het moeilijkste onderdeel van softwareontwikkelen is niet het juist bouwen, maar het juiste bouwen. Vaak zwoegen programmeurs dagenlang op hun code en worstelen testers zich door het resultaat heen, om er pas helemaal op het eind van de ontwikkelcyclus achter te komen dat er iets is gebouwd waar eindgebruikers niet helemaal (of: helemaal niet!) op zaten te wachten. Het scheppen van een juist beeld van wat er gemaakt moet worden is misschien wel de belangrijkste stap in het ontwikkelen van software - en niet zelden de minst ontwikkelde.