Schrijf gewoon geen bugs, man

Elke Software Engineer, Project Manager en QA heeft het meegemaakt: een strakke deadline nadert en er zijn nog steeds problemen met de software. Een pagina laadt niet, een API geeft constant foutmeldingen of een gebruiker kan berichten lezen die niet voor hun ogen bestemd zijn. Deze problemen noemen we “bugs”, vernoemd naar een klein insect dat in een computer kroop, het moederbord aanraakte en zichzelf samen met de pc roosterde. Niemand schrijft opzettelijk bugs.

En toch... gebeuren ze.

Elke dag. Overal.

Zelfs in de beste teams.

De vraag is:

Waarom gebeuren ze? En wat kunnen we doen om ze drastisch te verminderen?

Laten we het ontleden.

Waarom ontstaan bugs?

1. Iemand heeft een feature niet volledig ontwikkeld

Software schrijven is een vorm van kunst: het vereist een zorgvuldige afweging tussen duizenden componenten die samenwerken en de creativiteit om die componenten toe te voegen, te verwijderen of aan te passen om een betere oplossing voor een softwareprobleem te bieden.

Als een schilder de verkeerde verf op een droog canvas gebruikt, zal het schilderij na verloop van tijd vervagen. Precies zo zal de software zich onvoorspelbaar gedragen als een developer een component niet correct implementeert.

Soms is de hoofdoorzaak simpel: slechte gewoontes.

• Deadlines najagen zonder de zaken goed te doordenken

• Structuur en best practices negeren

• Codefragmenten kopiëren en plakken zonder ze te begrijpen

• Tijdelijke oplossingen die permanente 'hacks' worden

Wanneer code gehaast wordt geschreven, niet wordt beoordeeld door senior teamleden of onvoldoende wordt getest, is het slechts een kwestie van tijd voordat er een bug opduikt. Onthoud goed: slechte code ligt zelden aan slechte developers, het ligt vaak aan een slechte omgeving: tijdsdruk, onduidelijke verwachtingen of gebrek aan ondersteuning. Uiteindelijk had de developer niet de middelen om een feature volledig te ontwikkelen.

2. Geen (of gebrekkige) integratietesten

Elke module kan individueel slagen voor een test.

Maar het verbinden van modules zonder integratietesten is waar de chaos ontstaat.

Het testen van individuele bakstenen betekent niet dat het huis niet zal instorten.

Het testen van de structuur, hoe onderdelen samenwerken, is waar de echte kwaliteitscontrole plaatsvindt.

3. Third-Party packages die kapot gaan

Externe libraries en frameworks versnellen de ontwikkeling, totdat ze averechts werken.

• Updates introduceren 'breaking changes'

• Dependencies worden verouderd (deprecated)

• Beveiligingslekken sluipen naar binnen

Als je versiebeheer niet zorgvuldig aanpakt en dependencies niet monitort, bouw je je project op drijfzand.

Developers zijn niet als enige verantwoordelijk

Het vermijden van bugs is een teaminspanning.

En managers hebben een grotere rol dan de meesten beseffen.

Dit is wat jij - als (project)manager - kunt doen om je team te helpen betere, schonere code te schrijven:

1. Geef duidelijke instructies

Onduidelijke tickets zijn een recept voor bugs.

Vage doelstellingen leiden tot vage oplossingen.

Wees specifiek.

Definieer wat er moet gebeuren, waarom het belangrijk is en wat de stakeholders verwachten. Schrijf alle stappen op die nodig zijn om het doel te bereiken. Definieer de situatie vooraf en hoe het daarna zou moeten zijn. Leg uit hoe je tot de conclusie bent gekomen dat er iets moet gebeuren. Bovendien, als je merkt dat een ticket niet volledig is geïmplementeerd door ontbrekende vereisten, schets dan duidelijk wat er aan het ticket moet worden toegevoegd of gewijzigd om aan de verwachtingen te voldoen.

2. Verifieer het ticket

Voordat je een taak naar een volgende fase verplaatst, verifieer je of deze echt voltooid is.

Het is ontzettend frustrerend voor een QA Engineer om een ticket te ontvangen om te testen, om er vervolgens achter te komen dat er helemaal geen feature is om te testen. Het is hun taak om verschillende testscenario's te bedenken, een oplossing vanuit verschillende perspectieven te bekijken en de uitkomst van mogelijke acties te testen. Het is niet hun taak om tickets constant terug te sturen naar developers met de boodschap dat ze hun werk beter moeten doen.

Vraag niet alleen aan de developer "Werkt dit?" voordat je een ticket verplaatst. Vraag de developer in plaats daarvan om te laten zien dat het werkt. Op dezelfde manier: wanneer een QA een ticket goedkeurt voor productie, vraag hen dan kort om hun testflow nog één keer te doorlopen terwijl je meekijkt.

Je zult versteld staan hoeveel tijd - en conflict - bespaard blijft door een simpele verificatie of het ticket dat je verplaatst ook daadwerkelijk klaar is.

3. Creëer een cultuur van teaminspanning

Software schrijven vereist een enorme hoeveelheid mentale focus om componenten succesvol te combineren tot een volledig uitgewerkte feature. Het is geen verrassing dat vooral minder ervaren developers vaak dingen over het hoofd zien, maar zelfs senior developers kunnen wel eens een steekje laten vallen.

Een team om je heen hebben dat kan bijspringen als het moeilijk wordt, bespaart niet alleen tijd, maar verbetert ook de kwaliteit van de output. Code is bedoeld om door andere developers te worden onderhouden, dus het is belangrijk om te verifiëren of het onderhoudbaar is voordat het naar productie gaat.

Peer reviews dwingen het volgen van best practices en teamstandaarden af. Bovendien stimuleren ze het leerproces binnen het hele team. Creëer een cultuur waarin developers zich op hun gemak voelen om hun code en oplossingen te bespreken.

Teamwork makes the dream work.

4. Houd developers (tijdelijk) in een focus-bubbel

Context switching is de vijand van 'deep work'.

Wanneer developers van begin tot eind gefocust blijven op dezelfde feature:

• Begrijpen ze edge cases beter

• Merken ze inconsistenties eerder op

• Bouwen ze stabielere code

Developers laten springen tussen verschillende taken en projecten doodt de productiviteit en vergroot de kans op fouten.

Laat ze focussen.

5. Motiveer je developers

Bugs nemen toe wanneer mensen zich gestrest voelen, gemanaged worden op microniveau of constant worden onderbroken.

Geef developers de ruimte voor diepe focus.

Vertrouw erop dat ze hun eigen workflow kunnen beheren.

Moedig trots op schone, doordachte code aan.

Gelukkige, gefocuste developers bouwen betere producten. Zo simpel is het.

6. De 'blameless postmortem' filosofie

Fouten zullen gebeuren. Tenminste, als je daadwerkelijk iets aan het ontwikkelen bent.

Een essentieel hulpmiddel om met deze problemen om te gaan zijn postmortems. Een bekend concept om een incident vast te leggen en hoe ermee is omgegaan, om te voorkomen dat het opnieuw gebeurt en om kennis te hebben over hoe om te gaan met soortgelijke problemen in de toekomst.

Wanneer een bug opduikt, focus dan op het probleem in plaats van op de betrokken personen. Je kunt mensen niet "repareren", maar je kunt wel systemen en processen verbeteren om mensen beter te ondersteunen bij het maken van de juiste keuzes tijdens het ontwerpen en onderhouden van complexe systemen.

Stel de volgende vragen:

• Wat ging er mis in het proces?

• Hoe kunnen we het herstellen?

• Wat kunnen we hiervan leren?

Zodra het probleem is opgelost, documenteer je alles in een postmortem, maar wijs niet met de vinger! Behandel het incident alsof iedereen in het team deze fout had kunnen maken. Houd de postmortem constructief door te focussen op acties. Zodra je ervan hebt geleerd, deel je de lessen met het engineeringteam of via een interne mailinglijst. Beoordeel postmortems net zoals je code zou beoordelen.

Bugs zullen gebeuren.

Maar je kunt kiezen hoe je ermee omgaat.

Je kunt niet alle bugs elimineren.

Maar je kunt processen bouwen die ze vroegtijdig opsporen en een cultuur creëren die de frequentie ervan verlaagt.

Bij We Do Dev Work geloven we dat het schrijven van schone, betrouwbare code niet alleen om technische vaardigheid gaat.

Het gaat om communicatie, helderheid, focus en eigenaarschap.

Omdat goede ontwikkeling geen magie is.

Het is een gewoonte, steen voor steen opgebouwd.