Over boeken en boekenclubs (1/3)
Het beste werkgerelateerde advies dat ik ooit heb gekregen, kreeg ik van mijn eerste manager. Ik was nog maar net begonnen als softwareontwikkelaar en worstelde met de enorme complexiteit die kwam kijken bij het onderhouden van een legacy codebase. Hij zei (ik parafraseer): “Je hebt de ballen verstand van softwareontwikkeling. Houd de vrijdagen vrij voor zelfstudie, en lees eens een boek.”
Ik vluchtte voor een PI-planning en wat er toen gebeurde zul je niet geloven
Hoe vaak komt het niet voor dat je met je team een besluit neemt – met de twijfelachtige zegening van schoorvoetend instemmende collega’s die het achterste van hun tong zorgvuldig uit zicht houden? Of erger nog: dat jullie unaniem een knoop doorhakken om er een paar dagen, weken of maanden later te moeten constateren dat die knoop massaal de wind in wordt geslagen?
Wat is refactoring (volgens Hannah Arendt)?
Wat kunnen Hannah Arendts filosofische overpeinzingen ons leren over refactoring? Nou, bijvoorbeeld waarom de metafoor van technische schuld een misleidende is. Maar als refactoring niet het afbetalen van technische schuld is, wat is het dan wel? En wat betekent dat voor de rol die refactoring in onze dagelijkse werkzaamheden in mag (of moet?) nemen?
Koppeling buiten code om
Koppeling is: wanneer een wijziging in het ene systeem een wijziging in het andere systeem noodzakelijk maakt. Wanneer softwareontwikkelaars het over koppeling hebben, dan bedoelen we meestal: in code aan elkaar gekoppelde systemen. Maar twee systemen kunnen ook zuiver functioneel aan elkaar gekoppeld zijn, zonder ook maar één regel code te hoeven delen.
De bouwmetafoor gaat niet eens op voor de bouw
De bouw anno nu heeft veel ideeën uit agile en lean geïncorporeerd en heeft daarom tegenwoordig – grappig genoeg – meer weg van softwareontwikkeling dan je zou verwachten. Dus niet alleen softwareontwikkeling is niet als het bouwen van een huis – zelfs het bouwen van een huis blijkt niet als het bouwen van een huis!
Sabotage!
Onlangs volgde ik een training Deep Democracy – en werd ik bewust gemaakt van enkele valkuilen en disfunctionele patronen in samenwerking. Eén van de interessantste inzichten die ik opdeed hadden te maken met sabotage: het ondermijnen van (een deel van) de groep. Dat kan op allerlei manieren gebeuren, van het maken van (sarcastische) grappen tot roddelen tot tegenwerken of zelfs staken. Het zijn allemaal voorbeelden van “ja zeggen maar nee doen.”
Feature branches belemmeren een beter begrip van koppeling
Laatst brak een kleine wijziging aan de back-end – die we zo snel mogelijk richting de testomgeving hadden gebracht – functionaliteit aan de front-end. Voor mijn collega was het een ideale gelegenheid om zijn bias voor Gitflow bevestigd te zien. “Dit zou nooit gebeurd zijn als we van feature branches gebruik hadden gemaakt!” concludeerde hij. – En niet onterecht, want het apart houden van de wijziging in kwestie zou de functionaliteit op testomgeving inderdaad intact hebben gehouden.
Borrelpraat
“Proost!” – en toen begon iemand over de uitvinding van het getal 0, en hoe bizar het is dat er ooit een tijd is geweest dat er geen nul was. Dit is de ultieme borrelpraatvraag: is 0 ontdekt of uitgevonden?
Hoge cohesie, losse koppeling
Het mag gerust een cliché heten: bij het ontwerpen van software streven we naar hoge cohesie (high cohesion) en losse koppeling (loose coupling). Met andere woorden: de modules die we ontwerpen moeten inhoudelijk één geheel vormen, en niet onlosmakelijk verbonden zijn met andere modules; wijzigingen in de ene hoek zouden minimale gevolgen moeten hebben voor andere hoeken van het systeem. Systemen met hoge cohesie en losse koppeling worden ook wel modulair genoemd.