Tag boeken
Agile zijn, niet Agile doen
Heeft Agile gefaald? Of heeft Agile nooit écht een voet aan de grond gekregen? In Clean Agile pleit Robert “Uncle Bob” Martin voor dat laatste. Het succes van Agile is zowel een vloek als een zegen geweest. Een zegen, omdat het het inefficiënte Waterval heeft verdreven, maar een vloek omdat de kerngedachte achter Agile zo vaak verkeerd begrepen is dat deze geheel verloren dreigt te gaan. Clean Agile is zijn poging de vele misverstanden recht te zetten.
Anderen veranderen met hun eigen argumenten
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.
Schorseneren en software architectuur
Een ontwerper van een systeem - of dat nu een kok is of een softwarearchitect - dient niet alleen rekening te houden met de functionele eigenschappen van zijn componenten. Smaak is niet alles! Een lekker ingrediënt kan om allerlei redenen niet in een gerecht terechtkomen. De impact van het ingrediënt op de afwasser - niet onbelangrijk! - kan dusdanig zijn dat het verstandig is om toch maar een ander smaakje te kiezen.
Iteratieve verfijning
Dat software ontwikkelen - vandaag de dag in elk geval - een iteratief proces is, is een plattitude. Dat ook de voorbereidingswerkzaamheden van programmeren iteratief kunnen (of moeten?) worden vormgegeven, is iets wat ik misschien wel wist, maar me nooit helemaal beseft heb. Het interessante van Scrum (en van softwareontwikkeling in het algemeen) is dat je het jarenlang kunt doen, en toch steeds opnieuw best en better practices kunt ontdekken - of herontdekken.
Stap voor stap software testen
Software testen is een vak apart. Veel ontwikkelaars hebben wel een schetsmatige notie van hoe een goede test eruit dient te zien, maar ontberen een gedegen theoretisch fundament. Zulke ontwikkelaars zouden er goed aan doen om Essentials of Software Testing van Ralf Bierig, Stephen Brown, Edgar Galván en Joe Timoney te lezen.
Wie is verantwoordelijk voor jouw ontwikkeling?
Wie zijn vakinhoudelijke ontwikkeling afhankelijk maakt van zijn werkgever, zegt eigenlijk die ontwikkeling zelf niet zo belangrijk te vinden. Maar je persoonlijke ontwikkeling is wel belangrijk. Daarom is het essentieel dat je daar zelf de leiding in neemt. Als jij het niet belangrijk genoeg vindt om er tijd en geld in te steken, hoe kun je dan van je werkgever verwachten dat die dat wel doet?
Meer dan een zwarte doos
De basis van een programmeren kost je misschien een weekendje, maar een goed programma leren schrijven, dat is een proces van jaren. Waarom? Het besef dat een goed programma meer is dan een werkend programma, daalt pas na veel vallen en opstaan in. Studenten en beginnend programmeurs die meer uit hun strubbelingen willen halen, doen er daarom goed aan Perdita Stevens' How to Write Good Programs aandachtig te lezen.
Wat er gebeurt wanneer je op 'save' klikt
De theorie achter relationele databases en een goede beheersing van SQL is essentieel voor softwareontwikkelaars vandaag de dag. Studenten en professionals die hun kennis willen opfrissen, kunnen voor een toegankelijke inleiding in dit onderwerp terecht bij Relationele databases en SQL van Leo Wiegerink, Jeanot Bijpost en Marco de Groot. Dit relatief lijvige boekwerk (520 pagina’s) maakt de lezer in een aangenaam tempo bekend met de basis van de onderwerpen in de titel.
Moet je dit willen testen?
“Code is a liability, not an asset.” Van alle zinnen in Vladimir Khorikovs Unit Testing: Principles, Practices, and Patterns is deze me het meest bijgebleven. Ironisch, want op het eerste gezicht is het geen zin die iets te doen heeft met unit testing. Maar ook testcode kan een een blok aan het been zijn. Bijvoorbeeld wanneer je de code eigenlijk niet zou moeten willen unittesten.
Breek je test
In Martin Fowlers Refactoring vond ik een interessante programmeertip: breek je test. Ja, dat lees je goed.