Onderhoudbaarheid tip 1: Gebruik een Agile ontwikkelaanpak

Agile software development

Er zijn veel boeken geschreven over Agile Software development, Scrum en Kanban. De kern van de boodschap is dat software onderhevig is aan veranderingen (voortschrijdend inzicht) en communicatieproblemen (begrijpen we elkaar wel). Een Agile aanpak speelt hierop in door iteratief te ontwikkelen: in korte sprints wordt de applicatie voorzien van steeds nieuwe of uitgebreide stukken functionaliteit die waarde hebben voor de gebruikers. Software groeit als een bloemkool.

Bloemkool

De applicatie groeit van de eerste functionaliteit via vele sprints door naar een applicatie met vele functies. De eerste functionaliteit moet vaak snel worden opgeleverd om enerzijds het idee te bewijzen (MVP uit Lean Startup) en anderzijds om de concurrentie voor te blijven. Snelheid en toetsing zijn belangrijk. Onderhoudbaarheid, gezien de kleine omvang, minder. Vanaf dit moment gaat de hoeveelheid code groeien, doordat er steeds nieuwe functionaliteit wordt toegevoegd die de bestaande code uitbreidt. Wanneer we dit ongecontroleerd laten gebeuren, is de bloemkool-metafoor zichtbaar en is de kans op Spaghetticode groot. (Vergelijkingen met voedsel zijn blijkbaar populair binnen ons vakgebied.) Wanneer we vooraf volledig zouden kunnen overzien welke functionaliteit de applicatie in detail zou gaan bevatten, zou de applicatie in één keer goed ontwikkeld kunnen worden: de watervalmethode. Refactoren (zie deel 1) zou niet nodig zijn. Dit dogma is hardnekkig en zorgt er mede voor dat aandacht voor refactoring tijdens het uitbreiden van de applicatie met nieuwe functionaliteit (en dus code) vaak beperkt is. Nadruk op snelheid, kostenbesparing en de overtuiging ‘het werkt toch’ overheersen. Terwijl uit onderzoekt simpelweg blijkt dat de kwaliteit van beter onderhoudbare code hoger is, en de Total Costs of Ownership lager (The Economics of Software Quality – Jones & Bonsignour).

Gebruik een Agile ontwikkelaanpak

Kortom: door in het ontwikkelteam te erkennen dat software wijzigt, zal onderhoudbaarheid onderdeel worden van de mindset van het ontwikkelteam. Maak het team verantwoordelijk voor de consequenties van hun werk. Werk met:

• DevOps principes als you build it, you run it’: laat developers de pijn van slechte onderhoudbaarheid voelen;
• korte iteraties (twee à drie weken), gericht op functionaliteit: hierdoor wordt de invloed van voortschrijdend inzicht en communicatieproblemen tijdens de bouw beperkt;
• een Definition of Done*waarin testen en deployment zijn benoemd: testbaarheid draagt bij aan onderhoudbaarheid;
• opleveringen op een productieomgeving (go-live kan desgewenst later): code bewijst zich pas in productie, dus doe dit zo snel mogelijk;
• review van code door andere ontwikkelaar in het team: zorg vroegtijdig voor kennisborging en gedeelde verantwoordelijkheid voor de code;
• pairprogramming voor complexe onderdelen: bouw direct gedeelde verantwoordelijkheid op voor de onderhoudbaarheid;
• refactoring ter beheersing van technical debt: wanneer de hoeveelheid technical debt onbeheersbaar wordt, daalt de productiviteit enorm. Wees transparant naar de Product Owner over de hoeveelheid technical debt, de impact op de productiviteit en de opties het te verminderen. Hierover in een volgend deel meer. De komende weken staan we stil bij de andere zes tips om de onderhoudbaarheid, en daarmee de productiviteit en wendbaarheid, van maatwerk applicaties op het gewenste niveau te brengen en te houden.