Building Quality Software Part 2

Have you read the previous blog yet?: Building Quality Software, Part 1

Alex’ agenda zit helemaal vol met vergaderingen, één-op-één gesprekken en deadlines. Werken in drie verschillende teams tegelijk blijkt een flinke uitdaging en Alex verlangt naar meer focus in plaats van de huidige chaotische versnippering. Toch is het duidelijk dat alle drie de teams hulp kunnen gebruiken, vooral het Public Website team dat Alex pas twee weken geleden is komen versterken. De Product Owner heeft al meerdere keren benadrukt dat de “WOTY” (Website of the Year) een grote aangelegenheid is en dat er nog maar drie maanden resten voordat de jury de winnaar kiest. Het ontwikkelteam weet echter niet goed wat er precies moet gebeuren om hun winstkansen te vergroten.

“Het is eigenlijk heel simpel,” zegt de meest ervaren ontwikkelaar tijdens de Sprint Planning. “We worden beoordeeld op één ding: gebruikerstevredenheid. Daar moeten we ons op richten.” De Scrum Master lacht. “Dus ik neem aan dat de Product Owner gewoon een verhaal toevoegt aan de backlog, het ‘Satisfaction’ noemt en dat we dan aan het eind van de sprint klaar zijn?” “Ik weet dat je een grap maakt,” zucht een van de front-end ontwikkelaars, “maar dat is eigenlijk nog de beste aanpak die we hebben. We zullen het gewoon op gevoel moeten doen.”

“Sorry,” zegt een derde ontwikkelaar met hoorbare verwarring in zijn stem. “Waarom raken we in paniek? Volgens mij hebben we juist al veel gedaan om ervoor te zorgen dat we de best mogelijke website hebben. We genereren vrijwel geen fouten en de weinige die we zien lossen we razendsnel op. We hebben praktisch geen downtime. We gebruiken queue based oplossingen om dataverlies te voorkomen als er toch iets misgaat. Onze website is eerlijk gezegd geweldig.” “En we maken veel winst,” voegt de Product Owner toe met een glimlach.

“Ik ben het daar grotendeels mee eens,” zegt Alex. “Maar niets van wat jullie net noemden is waar de jury naar zal kijken. En eerlijk gezegd is het ook niet waar onze echte gebruikers ons op beoordelen.”

Gebruikers verliefd laten worden op je software

In het vorige deel van deze reeks stelde ik dat kwalitatieve software doelen en meetpunten nodig heeft om die doelen te bereiken. Ik besprak drie gebieden waarin doelen en meetpunten essentieel zijn om kwaliteit te bepalen, te vestigen en te behouden: juistheid, gemeten in het aantal fouten; betrouwbaarheid, gemeten in de hoeveelheid uitvaltijd; en kosten, gemeten met de verhouding tussen winst en uitgaven.

Dat brengt me bij een gewaagde stelling van vandaag: geen van deze zaken doet er voor je gebruikers toe. Niemand houdt van software vanwege de juistheid, betrouwbaarheid of winstgevendheid. Gebruikers gaan er simpelweg vanuit dat jouw applicatie volledig correct en betrouwbaar is. En ze geven er niets om of de applicatie winst oplevert of verlies draait. Hoge juistheid, betrouwbaarheid en winstgevendheid zullen gebruikers nooit verliefd maken op je applicatie. Tegelijkertijd geldt dat een applicatie met veel fouten of een slechte uptime juist snel irritatie oproept en tot afkeer leidt.

Dus wat zorgt ervoor dat gebruikers van jouw applicatie houden? Gebruikerstevredenheid is vaak, hoewel niet altijd, de belangrijkste voorspeller van succes. In dit tweede deel van mijn bespreking van kwalitatieve software behandel ik opnieuw drie aandachtspunten. Dit keer zijn het factoren die vaak een positief verband hebben met gebruikerstevredenheid: prestaties, bruikbaarheid en integreerbaarheid. Ik zal elk van deze factoren toelichten en daarbij ook meetpunten aanreiken om ze te volgen.

Maar voordat we dat doen, moeten we eerst een stap terugzetten. In het vorige deel noemde ik DevOps kort bij het bespreken van betrouwbaarheid. Deze keer verdient het onderwerp meer aandacht. DevOps biedt veel voordelen, maar in de context van deze blog springt één voordeel eruit: het gebruik van DevOps hangt sterk samen met hogere gebruikerstevredenheid. Daarom wil ik DevOps hier uitgebreider toelichten, omdat naar mijn mening nog te veel ontwikkelaars niet goed begrijpen wat DevOps precies inhoudt en waarom het belangrijk is.

De cruciale feedbacklus

DevOps is een combinatie van twee disciplines: development en operations. Deze combinatie is mogelijk om twee redenen. De eerste reden is een focus op ontwikkel- en operationele efficiëntie en automatisering. Het gebruik van tools, continue integratie, continue uitrol en goed geïnformeerde planning staan centraal om DevOps te laten werken. De tweede reden is de nadruk op samenwerking en communicatie tussen, of zelfs de samensmelting van, ontwikkelteams en IT-operationele teams. Het uiteindelijke doel van DevOps is om software sneller en betrouwbaarder te leveren.

De DevOps-cyclus bestaat uit meerdere fasen, elk met eigen tools en processen. Het belangrijkste onderdeel van DevOps, althans voor mij, is de feedbacklus. In DevOps hoort de ontwikkelcyclus voortdurend terugkerend en zelfversterkend te zijn. Elke fase voedt de volgende, waardoor er meer inzicht ontstaat en snellere, betere beslissingen worden genomen. De enige manier om deze cyclus op hoge snelheid draaiende te houden, is door automatisering van het ontwikkelproces, wat een kernprincipe van DevOps is.

De eerste fase is de planningsfase, waarin feedback wordt verzameld en verbeteringen voor de toekomst worden voorbereid. Dit gebeurt met tools als Jira, Trello of Asana, die helpen bij het volgen van voortgang en het stellen van prioriteiten. Het probleem bij veel teams is dat de planning gebaseerd is op persoonlijke voorkeuren van product owners, vage bedrijfsdoelen of, nog erger, het inhalen van al gemiste deadlines.

Daarna volgt het bouwen van de geplande wijzigingen in de software. Dit omvat het schrijven en beoordelen van code. DevOps vereist dat ontwikkelaars versiebeheersystemen zoals Git gebruiken om veranderingen te beheren. Automatisering in deze fase helpt vooral om de complexiteit voor ontwikkelaars zo laag mogelijk te houden.

De volgende fase is continue integratie, waarbij (een deel van) de volledige codebase automatisch wordt gecompileerd tot uitvoerbare, publiceerbare bestanden. In de context van DevOps betekent CI dat dit proces plaatsvindt telkens wanneer er wijzigingen worden doorgevoerd. Buildtools zoals Maven, Gradle of Ant maken dit proces sneller en betrouwbaarder. Ze zorgen ervoor dat alle afhankelijkheden worden opgenomen en dat de code consistent is in verschillende omgevingen. In deze fase wordt ook gecontroleerd of de software naar behoren werkt, met behulp van tests zoals unit-, integratie- en end-to-endtests. Testautomatisering is een cruciaal onderdeel van DevOps, omdat het mogelijk maakt om software snel en consistent te testen. Handmatig testen is simpelweg te traag voor een feedbacklus.

De vierde fase is de uitrolfase, waarin de software naar productieomgevingen wordt gebracht. Ook hier is automatisering essentieel om de feedbacklus snel te houden. Tools zoals Jenkins of CircleCI kunnen hiervoor worden ingezet. Automatisering zorgt er bovendien voor dat de software consistent en correct wordt geïnstalleerd.

Na de uitrol volgt de operationele fase. Hier gebruiken mensen de software en onderhouden anderen deze. Voor een echte feedbacklus moeten we zoveel mogelijk gebruiksgegevens verzamelen en omzetten in inzichten die helpen bij de volgende planningsfase. Zo ontstaat continue feedback, de laatste fase van de cyclus, voor zover een cyclus een einde kan hebben. Deze feedback bestaat uit technische data, zoals logbestanden, systeemgezondheid, uitvaltijd en fouten (monitoring), maar ook uit functionele data, zoals gebruikersgedrag (analytics). Zelf werk ik veel met Azure Cloud, dus ik heb veel ervaring met Azure Monitor en de Log Analytics Workspace voor monitoring. Voor analytics raad ik Matomo en Microsoft Clarity aan.

DevOps stelt dat er geen echte waarde kan worden gecreëerd zolang operations en development te gescheiden zijn, omdat ze onderdeel zijn van dezelfde cyclus.

Wanneer DevOps niet werkt

DevOps is naar mijn mening bijna een vereiste om kwalitatieve software te kunnen maken. Maar noodzakelijk of niet, het werkt niet altijd. Ik vergelijk het graag met Agile. Strikt genomen is DevOps geen onderdeel van de Agile-familie, maar het werkt bijzonder goed in combinatie met bepaalde Agile-methodieken zoals Lean, SCRUM en Kanban. Toch is Agile geen wondermiddel en past het niet bij elk softwareproject. In een voorspelbare context kan Agile juist extra overhead veroorzaken, waardoor de kosten hoger worden dan de baten.

Iets vergelijkbaars geldt voor DevOps. In sommige situaties werkt het uitstekend, in andere helemaal niet. Ik heb vijf contexten geïdentificeerd waarin DevOps geen goede keuze is voor een softwareproject. Er is helaas geen handige matrix om dit visueel te maken, maar de informatie is belangrijk genoeg om te delen.

Ten eerste, als het softwareontwikkelproces van een organisatie afhankelijk is van verouderde systemen of handmatige procedures, kan de overstap naar DevOps overweldigend lijken. Een plotselinge overgang is vaak niet haalbaar voor organisaties die al jaren met monolithische software werken. In dat geval is een gefaseerde aanpak beter, waarbij DevOps-principes geleidelijk worden ingevoerd om de weg naar verandering voor te bereiden.

Ten tweede, in sectoren zoals financiën, gezondheidszorg en overheid zijn naleving en beveiliging van het grootste belang. Het verstoren van bestaande processen kan nalevingsproblemen veroorzaken en veiligheidsrisico’s opleveren met mogelijk rampzalige gevolgen. Bedrijven in gereguleerde sectoren moeten strikt vasthouden aan procedures en protocollen en grondige evaluaties uitvoeren voordat ze veranderingen doorvoeren.

Ten derde, tijdens fusies, overnames of afsplitsingen kunnen de gevolgen voor softwareontwikkeling groot zijn. Organisaties moeten hun ontwikkelmethodes opnieuw afstemmen op nieuwe bedrijfsdoelen. In zulke situaties is een DevOps-transformatie vaak geen verstandige investering, en moet eerst de verwachte opbrengst zorgvuldig worden beoordeeld.

Verder kan het voorkomen dat organisaties midden in een softwarecrisis zitten en in paniek besluiten om DevOps in te voeren. Dat is meestal niet effectief. In zulke gevallen is het belangrijk om eerst de kern van het probleem te vinden. Pas daarna kan het invoeren van specifieke DevOps-processen of -tools zinvol zijn, zonder een volledige transformatie te hoeven doorvoeren.

Tot slot, voor bedrijven die maar zelden software releasen, levert DevOps weinig op. DevOps is bedoeld om de efficiëntie, wendbaarheid en automatisering van softwarelevering te verbeteren. Maar als een organisatie maar enkele keren per jaar software uitbrengt, wegen de inspanningen en investeringen niet op tegen de opbrengst.

Misschien klinkt het vreemd dat ik beweer dat DevOps nodig is voor kwalitatieve software, maar tegelijkertijd zeg dat het niet overal past. Betekent dit dat als DevOps geen optie is, je ook geen kwalitatieve software kunt leveren? Ja, eigenlijk wel. Als DevOps geen haalbare keuze is, is de kans groot dat je óf geen kwaliteit kunt leveren óf dat kwaliteit simpelweg niet van je verwacht wordt.

Waarom gebruikers blijer zijn met DevOps

In het vorige deel bespraken we juistheid, betrouwbaarheid en kosten als aandachtspunten voor software-engineers. Dit keer wil ik drie andere aandachtsgebieden behandelen die direct invloed hebben op de gebruiker: prestaties, bruikbaarheid en integreerbaarheid. Traditionele softwareontwikkeling, zonder DevOps, houdt meestal wel rekening met de eerste drie, maar veel minder met de laatste drie. Dat komt doordat die pas zichtbaar belangrijk worden voor operationele teams.

Door ontwikkeling en operations te combineren, vergroten teams niet alleen de kans dat ze álle factoren meenemen, maar ook hun vermogen om ze nauwkeurig te meten en inzichten te halen uit echte gebruiksdata. Het is relatief eenvoudig om vooraf te bepalen wat een applicatie moet doen, maar veel moeilijker om in te schatten hoe lang dat mag duren of wat de prettigste manier is voor de gebruiker om ermee te werken. DevOps helpt teams bij dit soort vraagstukken.

Daarom vind ik dat softwareontwikkelaars altijd moeten streven naar het toepassen van DevOps en de focus moeten leggen op automatisering van het ontwikkelproces. Je hoeft niet tot het operationele team te behoren, maar je bent wél verantwoordelijk voor de juiste tools en processen om tijdens de operationele fase de applicatie te monitoren en analyseren. Als de feedbacklus niet gesloten is, moet de software-engineer degene zijn die dat opmerkt en een oplossing zoekt. Als het ontwikkelproces te traag is, is de software-engineer de aangewezen persoon om het te versnellen.

En misschien wel het belangrijkste: als de gebruikerstevredenheid laag is, dan gaat er iets mis in het werk van de software-engineer.

De behoefte aan snelheid

Prestaties meten hoe goed een softwareapplicatie voldoet aan de verwachtingen van de gebruiker, door te analyseren hoeveel tijd en middelen nodig zijn om een dienst te leveren. Gebruikers willen altijd snellere software, maar optimaliseren voorbij een bepaald punt levert vaak geen merkbaar verschil meer op. De sleutel tot goede prestaties ligt in het stellen van realistische doelen die rekening houden met zowel de wensen van de klant als de technische haalbaarheid.

Een veelgebruikte methode om prestaties te meten is load testing, waarbij gebruikersverkeer wordt gesimuleerd om te zien hoe het systeem presteert onder zware belasting. Andere belangrijke meetpunten zijn responstijd (de tijd die het systeem nodig heeft om te reageren), doorvoer (het aantal transacties dat binnen een bepaalde tijd wordt verwerkt) en resourcegebruik (hoeveel CPU, geheugen en andere middelen worden gebruikt).

Om prestaties te verbeteren, kunnen ontwikkelaars verschillende technieken toepassen zoals caching (met aandacht voor privacy en beveiliging), parallelle verwerking en optimalisatie-algoritmes. Het is echter belangrijk te weten wanneer deze technieken zinvol zijn. Optimalisaties moeten zich richten op onderdelen waar gebruiksdata aantonen dat verbetering echt nodig is.

Een interessant aspect is dat het gevoel van snelheid soms belangrijker is dan de werkelijke snelheid. Technieken als voortgangsbalken, asynchrone processen en wachtrijen kunnen gebruikers het idee geven dat een applicatie snel is, zelfs als dat technisch niet het geval is. Dat is de illusie van prestatie, maar wel een effectieve.

Rage clicks, dead clicks en quick backs

Gebruiksvriendelijkheid meet of de eindgebruiker de software intuïtief en eenvoudig vindt om te gebruiken. Het ontwerp van de gebruikersinterface speelt hierin een cruciale rol. Klanten verwachten dat software makkelijk te gebruiken en te navigeren is, en wanneer die verwachting niet wordt waargemaakt, leidt dat tot frustratie en verminderde productiviteit.

Een belangrijk onderdeel van gebruiksvriendelijkheid is toegankelijkheid: de mogelijkheid voor mensen met een beperking of speciale behoeften om de software te gebruiken. Dit onderwerp is zo belangrijk dat ik er in een later deel dieper op zal ingaan.

Gebruiksvriendelijkheid is subjectiever dan prestaties, maar er bestaan wel manieren om deze te meten. Een veelgebruikte methode is handmatig gebruikersonderzoek of enquêtes, waarbij wordt geobserveerd hoe gebruikers met de software omgaan om knelpunten of verwarring te ontdekken. In mijn ervaring is dit hooguit een aanvullende methode, omdat het tijdrovend is, moeilijk te automatiseren en dus geen onderdeel vormt van een snelle feedbacklus. Een beter passende DevOps-meting is het aantal klikken dat nodig is om een taak te voltooien. Minder klikken betekent meestal een hogere gebruiksvriendelijkheid.

Binnen analytics vinden we nog meer relevante meetpunten. Deze veronderstellen een interface die gebaseerd is op klikken of tikken. Rage clicks ontstaan wanneer gebruikers herhaaldelijk op een element klikken of tikken, wat duidt op frustratie. De oorzaken kunnen uiteenlopen: trage prestaties, kapotte functies of een onduidelijk ontwerp. Wat de oorzaak ook is, rage clicks wijzen altijd op frustratie en een lagere tevredenheid. Dead clicks ontstaan wanneer gebruikers klikken op niet-interactieve onderdelen. Dit wijst op een onverwachte of slechte gebruikerservaring, meestal veroorzaakt door misleidend ontwerp. Quick backs ontstaan wanneer gebruikers snel terugkeren naar een vorige pagina of sectie omdat de inhoud niet relevant of nuttig blijkt. Dit is een teken van een slechte gebruikersreis, onduidelijke navigatie of ontbrekende informatie.

Om gebruiksvriendelijkheid te verbeteren, kunnen softwareontwikkelaars technieken inzetten zoals user-centered design, prototyping en heuristische evaluatie. Tools zoals Figma helpen om ideeën visueel te maken, waardoor ontwerpbeslissingen bewuster worden genomen.

Geen integratie is frustratie

Integratievermogen beschrijft hoe eenvoudig software kan samenwerken met andere systemen om functionaliteit te vergroten of controle te verbeteren. Nu steeds meer systemen API-gebaseerd zijn, wordt integratie een essentieel onderdeel van softwareontwikkeling. Gebruikers verwachten dat software soepel samenwerkt met andere toepassingen, en als dat niet lukt, daalt niet alleen de productiviteit maar ook de tevredenheid. Goede integratie daarentegen kan gebruikersbinding juist versterken.

Integratie lijkt op het eerste gezicht tweerichtingsverkeer, maar in de praktijk gaat het meestal om een provider-consumer-relatie. Ofwel jij wilt iets ontvangen van een ander systeem, of je wilt dat anderen jouw systeem gebruiken. Het is belangrijk dat softwareontwikkelaars goed begrijpen welke rol hun applicatie vervult. Providers moeten zorgen voor generieke, toegankelijke integratie, terwijl consumers hun integratie specifiek kunnen afstemmen op één aanbieder.

Belangrijke meetpunten voor integratie zijn onder andere de integration lead time, de tijd tussen het besluit tot integratie en de daadwerkelijke realisatie, en het aantal beschikbare API’s of integratiepunten, inclusief de kwaliteit van de documentatie. Ook de gebruiksvriendelijkheid van de integratie zelf is een relevante factor: hoe eenvoudiger en gestandaardiseerder de implementatie, hoe beter het integratievermogen.

Om integratie te optimaliseren, kunnen ontwikkelaars open standaarden, een API-first aanpak en componenttesten toepassen. Vaak is het verstandig om bij integratie te kiezen voor uitbreidbare, generieke en aanpasbare oplossingen in plaats van specifieke, unieke interfaces. Het gebruik van feature toggles kan hierbij helpen. Deze optimalisaties moeten al tijdens de planningsfase worden overwogen, nog voordat de eerste integratie plaatsvindt.

Kwaliteitssoftware

Wat betekent dit alles nu in de praktijk? Hoe maak en onderhoud je als software-engineer kwalitatieve software? Het korte antwoord: met veel inzet. Het iets langere antwoord: door een zorgvuldige balans te vinden tussen juistheid, betrouwbaarheid, kostenoptimalisatie, prestaties, gebruiksvriendelijkheid en integratie, naast alle overige wensen van gebruikers, klanten en technische eisen. Die balans is alleen vol te houden als een softwareontwikkelaar het volgende kan afvinken:

Bewustzijn van de verschillende technische en functionele aandachtspunten van de software
Regelmatige bespreking en meting van doelen en resultaten
Inzicht in hoe alle teamactiviteiten bijdragen aan betere scores en meer waarde
Kennis en toepassing van DevOps-principes waar mogelijk
Het vermogen om dit alles duidelijk uit te leggen aan anderen

Met andere woorden: kwalitatieve software vraagt kennis van zowel kwaliteit als software.

Website van het Jaar

Een week later zit Alex opnieuw met het Public Website team in overleg. Alex heeft de Product Owner geholpen de beschikbare webstatistieken te begrijpen, en samen met het team zijn doelen opgesteld voor verschillende belangrijke meetpunten. Vandaag moet al dat werk vruchten afwerpen. De senior developer draait haar laptop zodat iedereen het dashboard kan zien, gevuld met grafieken, balken en diagrammen. “We wisten al dat niets onze gebruikers echt frustreerde,” zegt ze, “maar nu weten we ook welke onderdelen ze het meest waarderen.” Ze wijst op een lijst met de meest bezochte pagina’s.

“Hoewel deze pagina’s al behoorlijk snel zijn, moeten we ons richten op het verbeteren van de prestaties en vooral de waargenomen snelheid. Gebruikers bezoeken deze pagina’s vaak, dus elke verbetering heeft een groot effect. Daarnaast zien we dat mensen onze knoppen prefereren boven tekstlinks. Bijna al onze meest bezochte pagina’s worden via knoppen of navigatie bereikt, terwijl de minst bezochte pagina’s juist achter links zitten.”

De Product Owner knikt en wijst naar een diagram met dode klikken. “Deze dode klikken laten zien dat mensen verwachten dat deze tekst een link is. Waarom maken we dat niet gewoon zo?”

Alex stemt in en voegt eraan toe: “Hoewel het ons misschien niet helpt om de WOTY-award te winnen, valt me op dat sommige van onze populairste functies niet in de mobiele app zitten. Dat is een gemiste kans. We zouden onze API’s moeten uitbreiden zodat het App-team die functionaliteit ook kan gebruiken.”

Alex en het team hebben nog maar tweeënhalve maand, maar ze zetten alles op alles. Wanneer de deadline voorbij is en de jury haar oordeel heeft geveld, rest hen niets dan afwachten. De vreugde is groot wanneer blijkt dat ze tweede zijn geworden en in veel categorieën het hoogste hebben gescoord. Trots vraagt de Product Owner of er een banner aan de website kan worden toegevoegd om hun succes te vieren, en het team plant een klein feestje.

Tijdens de viering komt de projectmanager van een van Alex’ andere teams, het Public API team, plotseling binnen. “Hé!” zegt Alex met een glimlach. “Kom je meevieren?” “Sorry,” zegt de projectmanager met een ernstige blik. “Ik heb slecht nieuws.”

“Wat is er aan de hand?” vraagt Alex.

De projectmanager wrijft over zijn neusbrug, haalt diep adem en zegt dan: “We krijgen een audit.”