Houtbewerken vs software development
Jesse van Leeuwen - Oct 16, 2023
Twee jaar geleden heb ik een cursus meubelmaken gevolgd. Voor die tijd heb ik een aantal pogingen gedaan om meubels te maken. Die pogingen resulteerden vaak in een meubel dat functioneerde, maar het resultaat was niet iets om erg trots op te zijn. Dit motiveerde mij om een cursus te volgen om te leren hoe het echt moet. Als beginnende meubelmaker en ervaren software developer zie ik parallellen tussen houtbewerking en software development. Eerst zal ik belangrijke verschillen belichten. Daarna de overeenkomsten en tenslotte een aantal lessen die ik geleerd heb van het meubel maken en die ik toepas op software development.
De verschillen
Om te beginnen met een open deur: bij software development gaat het om software en bij het bewerken van hout ben je bezig met hardware. Op een beitel of zaag zit geen undo optie. Wanneer je eenmaal hout hebt weggehaald, dan is het niet mogelijk om dit weer terug te zetten. Je kan het proberen maar dat lukt haast niet zonder in te leveren op schoonheid en/of stevigheid. In sommige gevallen is het gelukkig wel mogelijk om een stuk hout dat te kort is voor het beoogde doel, te gebruiken als een ander kleiner onderdeel. Natuurlijk kan je altijd mislukte stukken hout gebruiken voor een gezellig kampvuurtje. Soms zou ik willen dat je (oude) code op een soortgelijke manier toch nog voor een prettig doel kan inzetten.
Als software developers streven we ernaar om zaken ontkoppeld te houden en op een dusdanige manier op te zetten dat verschillende componenten kunnen worden vervangen door een ander component met hetzelfde koppelvlak of dezelfde functie. Op het eerste gezicht is dit anders dan bij meubel maken. Bij een meubel moeten alle houtverbindingen precies op elkaar aansluiten en worden alle koppelvlakken door middel van lijm vastgelegd om een duurzaam resultaat op te leveren. Als we echter naar het grotere plaatje kijken is er ook binnen meubel maken sprake van de nodige ontkoppeling en uitwisselbaarheid. Wanneer er behoefte is aan een zitmeubel, dan kan de implementatie bestaan uit bijvoorbeeld een bank, een kruk of een stoel.
Persoonlijk probeer ik, in het meubel maken, kant en klare oplossingen zo veel mogelijk te vermijden. In deze hobby probeer ik zoveel mogelijk oplossingen zelf te bedenken met behulp van wat ik voorhanden heb. De ambachtsman in mij heeft ook weleens die neiging, als het gaat om software development. Er is altijd de, enigszins arrogante, gedachte: “Hoe moeilijk kan het zijn, om dit zelf te maken?”. Maar als er een kant en klare oplossing beschikbaar is en deze is inderdaad passend, dan heeft dat in software development over het algemeen de voorkeur boven de, dure, optie om het zelf te bouwen.
Overeenkomsten
Ondanks dat we bij een agile aanpak meestal niet alles tot in detail uit denken voordat we beginnen met het schrijven van code, is het bij zowel software development als bij houtbewerking verstandig om van tevoren goed na te denken over wat er moet gebeuren. Welke onderdelen heb ik nodig en welke raakvlakken hebben deze onderdelen?
Ook moet er goed nagedacht worden over welk gereedschap te gebruiken. Dan bedoel ik wat betreft development niet zo zeer welke IDE moet ik gebruiken? Maar meer, welke tooling of frameworks gebruik ik. Gereedschappen komen het best tot hun recht wanneer ze gebruikt worden voor hetgeen ze bedoeld zijn. Je kan bijvoorbeeld met een cirkelzaag een brede groef maken, door meerdere keren vlak naast elkaar een zaagsnede te maken. Een beter resultaat bereik je echter door een frees te gebruiken. In mijn geval beschik ik (nog) niet over alle gereedschappen, dus dan moet je soms creatief zijn met wat je hebt. In het geval van software development is het verstandig om niet té creatief te zijn met de tooling die je gebruikt. Het is verstandig om regelmatig te evalueren of je nog steeds de juiste middelen inzet, om het beoogde doel te bereiken en of er geen makkelijkere of goedkopere oplossingen zijn door gebruik te maken van andere hulpmiddelen.
Het principe van “De laatste loodjes wegen het zwaarst” is van toepassing op zowel het bouwen van software als op het bouwen van meubels. “Ik moet alleen nog maar tests schrijven” is een uitspraak die vaak aangeeft dat iemand halverwege is, met zijn of haar ticket. Bij het werken met hout worden de stappen waarin je werkt steeds kleiner naarmate je het einddoel nadert. Eerst zaag je een groot stuk hout weg, daarna bik je met hamer en beitel een mooie plak hout weg. Vervolgens haal je met alleen de beitel steeds dunnere plakjes hout weg. Als laatste, ben je fracties van millimeters weg aan het halen om de verbinding precies passend te maken.
Dat precies passend maken, brengt ons bij de volgende overeenkomst: de merge conflicten. Bij het werken met hout werk ik meestal niet parallel aan verschillende onderdelen, maar er zijn altijd momenten dat er zaken bij elkaar komen die niet blijken te passen. Of je maakt de klassieke fout dat je binnen- en buitenmaten door elkaar haalt. Gelukkig is het zo dat er ook bij houtbewerking meestal wel weer een alternatieve aanpak is om te bereiken wat je wil. Denk dan wel even goed na, of de alternatieve aanpak geen gevolgen heeft voor de rest van je ontwerp. Wanneer de hoogte van een kast verandert, denk dan ook aan de maten van de achterwand en de deuren.
Iets wat wel eens de nodige frustratie op kan leveren, is het feit dat de eindgebruiker maar een fractie van het werk ziet. Je kan uren hebben besteed aan een prachtige pen-en-gatverbinding onder de stoel, maar niemand die het ziet. Wanneer je echter bent vergeten om het zitvlak netjes glad te schuren dan krijg je dat meteen te horen. Zo ook met software. Heb je net een prachtige backend gemaakt, met geweldige test dekking, krijg je tijdens de demo te horen dat die ene knop de verkeerde kleur blauw is.
De lessen
Wat zijn lessen die ik geleerd heb uit de houtbewerking en die ik kan toepassen in software development?
De belangrijkste les: “Bezint eer ge begint”. Bij software development is het verleidelijk om meteen los te gaan op de code en aanpassingen te doen. Je kan het toch altijd nog terug draaien als het toch niet blijkt te werken. Ik heb gemerkt dat het mij helpt om eerst goed uit te denken wat er moet gebeuren. Het helpt mij hierbij om te doen alsof gemaakte wijzigingen niet zo makkelijk terug te draaien zijn. Door eerst een goed overzicht te maken van: wat ligt er aan bestaande code? Wat is het beoogde doel? En welke wijzigingen moet ik waar doorvoeren? Dit helpt me om doeltreffend te werk te gaan en voorkomt dat ik te veel tijd besteed aan een aanpak die later niet de beste blijkt te zijn.
Afwerking is extreem belangrijk. In het geval van houtbewerking zorgt dit ervoor dat verbindingen precies passen en lang meegaan. Maar ook voor het uiterlijk is een goede afwerking belangrijk. In het geval van software development zit de afwerking natuurlijk ook in het visuele aspect, maar misschien wel belangrijker is de afwerking in de code base. Afwerking in de zin dat de code leesbaar is. Dat klassen duidelijke en afgebakende verantwoordelijkheden hebben. Dat hetgeen goed (automatisch) te testen is. Dit zijn zaken die je van buiten niet ziet, maar waarvan het terecht is dat je er veel tijd en aandacht aan besteed.
Voor een goede afwerking is geduld nodig. Dat is ook iets wat het meubel maken mij geleerd heeft. De verleiding is groot om even snel iets in elkaar te zetten. In het geval van software kan je, net als bij houtbewerking, met de juiste gereedschappen snel tot resultaten komen. Soms is dat snelle resultaat genoeg, maar meestal is er meer afwerking nodig om een tevreden klant en een duurzaam resultaat te krijgen.