Bug-blindheid

Voor wie geen programmeur is, is dat waarschijnlijk een fijnere manier om naar de wereld te kijken, maar ik denk dat het genezen van deze "kwaliteits- of bug-blindheid" nuttig is voor programmeurs. Ik heb dit bij veel vrienden en kennissen gedaan door simpelweg op bugs te wijzen. Na een paar weken beginnen mensen die daarvoor openstaan, de bugs vaak ook zelf op te merken.

Omdat ik deze zaken opmerk, heb ik meerdere banen gehad waarbij directeuren, VP's en executives me vroegen om iets te evalueren wanneer ze een eerlijke mening wilden van iemand die waarschijnlijk problemen zou opmerken (en deze zou oplossen of het proces tot een oplossing zou sturen). Soms vind ik geen problemen, maar vaker vind ik kwesties die variëren van "mild" tot "matig". En soms zijn de problemen ernstig, tot het punt waarop men kan zeggen dat het product simpelweg niet werkt.

Deze laatste categorie vind ik mysterieus. Wanneer ik interne discussies lees over hoe een product in die staat is beland, zie ik vaak een stroom aan interne opmerkingen waarin staat dat het fantastisch is en goed werkt. Maar wanneer ik het product open en probeer te gebruiken, blijkt dat het alleen werkt als je een aantal niet-intuïtieve omwegen (workarounds) gebruikt. De kans is groot dat een normale gebruiker het product niet alleen niet kan gebruiken, maar ook een zo hilariserend of frustrerend slechte ervaring heeft dat ze dit aan hun vrienden vertellen.

Ik heb dit idee al een decennium in mijn hoofd, maar ik aarzelde om erover te schrijven omdat ik me afvroeg of ik misschien onbewust vreemde 'corner case'-scenario's triggerde die normale gebruikers niet raken. Maar nadat ik steeds vaker zag dat producten werden gelanceerd en volledig flopten omdat gebruikers tegen exact dezelfde problemen aanliepen als ik, geloof ik niet langer dat ik ongebruikelijke dingen doe. Als een product ernstig gebrekkig lijkt wanneer ik het gebruik, dan is dat waarschijnlijk ook zo. Met de huidige mogelijkheden van LLM's kan ik zelfs simuleren hoe normale gebruikers reageren, wat aantoont dat deze problemen in veel verschillende scenario's reproduceerbaar zijn.

Voorbeelden van blindheid

Ik zal geen specifieke voorbeelden geven van professionele opdrachten om constructieve en blameless redenen, maar hier zijn enkele willekeurige voorbeelden.

Zoekmachines en SEO-spam

Een tijd geleden analyseerde ik webzoekopdrachten en vond ik slechte resultaten bij Google, Bing en Kagi. Over het algemeen faalden de grote zoekmachines in het leveren van goede resultaten en toonden ze pagina's vol laagwaardige SEO-spam en zelfs scams. Op mijn schaal is dit "matig", niet "ernstig" (ernstig zou zijn als de zoekmachine de helft van de tijd 500-fouten geeft). Bijna niemand maakte bezwaar tegen mijn karakterisering van Google en Bing, maar mensen vertelden me dat ik ongelijk had over Kagi. Zelfs wanneer ze me hun eigen resultaten stuurden, zag ik geen enkel goed resultaat; het stond vol met spam. Toch bleven mensen volhouden dat de resultaten goed waren.

In abstracte zin begrijp ik dat fans van iets vaak blind zijn voor de gebreken ervan. Ik zie dit ook bij Volvo-fora. Hoewel betrouwbaarheidsdata (en de ervaring van monteurs) aangeven dat de betrouwbaarheid van Volvo matig tot slecht is, staan de fora vol met mensen die volhouden dat Volvo's tot de meest betrouwbare auto's behoren en dat de data onjuist zijn.

Software: Blackboard en Discourse

Een voorbeeld dat centraler staat bij dit onderwerp is Blackboard (cursusbeheersoftware). Toen dit de meest gebruikte software was aan universiteiten, werd het breed gehaat door zowel studenten als professoren. Wikipedia vermeldt zelfs dat Blackboard een van de meest gehate bedrijven in het onderwijs was geworden.

Toen ik jonger was, sprak ik iemand die bij Blackboard werkte en vroeg ik onbezonnen: "Hoe is het om te werken aan software die zoveel mensen haten?". Tot mijn verbazing was die persoon niet beledigd, maar verward. Hij dacht dat de software juist breed geliefd was. Het was verbazingwekkend dat een werknemer van een bedrijf dacht dat hun product geliefd was, terwijl iedereen in mijn omgeving het tegendeel beweerde.

Iets soortgelijks zag ik bij de webperformance van Discourse (forumsoftware). Medewerkers van Discourse dachten dat de performance geweldig was. Ik ontdekte echter dat Discourse code bevatte die het laden van pagina's bewust vertraagde om te sjoemelen met webperformance-metrieken zoals LCP. Dit gaat verder dan optimalisatie voor een benchmark; het is actieve misleiding die de gebruiker uiteindelijk benadeelt.

Sport en subjectieve perceptie

Ook buiten de programmeerwereld zie ik dit. Er is een basketballer die subjectief wordt beschouwd als de "viesste" speler van zijn tijd, vooral vanwege het frequent slaan naar de genitaliën van tegenstanders. Fans van zijn team merken dit echter vaak niet op of rechtvaardigen het als een "natuurlijke beweging" bij het rebounden of schieten.

Mensen hebben een sterk vermogen om negatieven te negeren in zaken waar ze fan van zijn, inclusief hun eigen werk of het werk van hun bedrijf. Ik lijk het tegenovergestelde te hebben: mijn gedachten gaan direct naar de gebreken in mezelf en mijn werk. Wanneer mensen me vragen: "Hoe zou je het vinden als iemand je werk bekritiseert?", is mijn antwoord dat ik juist graag kritiek krijg van mensen die gaten in mijn redenering kunnen schieten. Ik beschouw mijn eigen werk vaak als vol grote gebreken.

Gewoontevorming en mitigatie

Ik heb nagedacht over mijn eigen blinde vlekken. Als kind gebruikte een vriend mijn computer uit het tijdperk van de mechanische muis. Hij vond de muis onmogelijk te gebruiken omdat de cursor willekeurig bewoog. Toen ik ging zitten, had ik geen enkel probleem. Pas toen ik naar mijn eigen hand keek, zag ik dat ik mijn hand wild heen en weer bewoog om de cursor in een rechte lijn te krijgen. Ik was onbewust aangepast aan het vuil op de muisbal en compenseerde de grillige tracking met tegenovergestelde grillige bewegingen.

Ik realiseerde me dat ik veel van dit soort mitigaties heb ontwikkeld voor softwarebugs:

  • Google Docs: Vroeger typte ik direct een titel in een nieuw document, maar Google Docs voegde een vertraging toe waardoor de eerste tekens werden overschreven. Nu heb ik de gewoonte om eerst iets anders te doen voordat ik de titel wijzig.
  • Microsoft (intern): Toen ik bij Microsoft werkte, merkte ik dat ik (en anderen) de wifi-schakelaar van de laptop uitzetten vóór het inloggen. Er was namelijk een service die het inloggen vaak blokkeerde met de melding dat er geen logon-servers beschikbaar waren. Als de service echter helemaal geen verbinding kon maken, werd de check overgeslagen en kon je gewoon inloggen.

Een groot deel van computergeletterdheid is in feite het ontwikkelen van een bibliotheek aan dit soort onbewuste gewoontes om bugs te omzeilen.

Kwaliteitsblindheid in softwareontwikkeling

Een veelvoorkomende suggestie om kwaliteitsblindheid te overwinnen is "dogfooding" (je eigen software gebruiken). Dit is beter dan niets, maar het werkt alleen als mensen geen gewoontes ontwikkelen om de problemen in de software te omzeilen. Programmeurs zijn juist erg goed in het omzeilen van softwaregebreken, waardoor ze deze problemen vaak niet eens opmerken als ze er niet specifiek op letten.

Het maken van een app die gemakkelijk te gebruiken is, betekent in feite het overbodig maken van deze vreemde gewoontes. De reflex van veel ontwikkelaars is echter: "Hè? Het is toch makkelijk om X te doen, je moet alleen [complexe reeks handelingen die geen normale mens zou bedenken] uitvoeren."

Ik geloof dat het genezen van kwaliteitsblindheid mogelijk is, mits de persoon ontvankelijk is. Door simpelweg te wijzen op problemen die ze niet opmerkten, beginnen mensen na verloop van tijd bugs overal te zien.

Dit is cruciaal omdat ik teams heb gezien die producten lanceerden met een zeer kleine kans op succes vanwege ernstige kwaliteitsproblemen. Er is een verschil tussen bewust kwaliteit opofferen voor snelheid, maar in veel gevallen is er sprake van kwaliteitsblindheid: iedereen bij het project denkt dat ze iets van zeer hoge kwaliteit leveren, terwijl dat niet zo is.

Met de komst van coding agents is dit belangrijker geworden. Hoewel het makkelijker is dan ooit om software van lage kwaliteit te produceren, is het ook makkelijker dan ooit om de kwaliteit te verbeteren (betere performance, minder bugs). Maar om dat te doen, moet je eerst opmerken dat er verbetering mogelijk is.

***

Bijlagen en aanvullingen

Advertentie-blindheid Michael Malis (oprichter van Freshpaint) merkte op dat hij een soortgelijke blindheid ziet bij advertenties. Wanneer hij uitlegt dat hij ziekenhuizen helpt met marketing, vragen mensen vaak waarom ziekenhuizen überhaupt marketing doen, terwijl San Francisco vol staat met billboards en busadvertenties voor ziekenhuizen zoals UCSF en Stanford.

Aanvullende voorbeelden van mitigatie

  • Mac Laptops: Em Chu merkt op dat sommige Mac-laptops bij het ontwaken in een staat komen waarin het scherm zwart blijft met alleen een cursor. De oplossing is het fysiek sluiten en openen van het scherm. Veel gebruikers ontwikkelen onbewust een gewoonte om een seconde te wachten en eerst de trackpad aan te raken voordat ze inloggen.
  • Google Docs & Codex: Gary Bernhardt en Daniel Gibson beschrijven hoe zij uitgebreide workarounds hebben ontwikkeld voor bugs in Google Docs en Codex, variërend van specifieke toetsencombinaties (zoals de Shift-toets gebruiken om een screensaver te beëindigen) tot scripts die foutief gedrag monitoren en corrigeren.
  • Twitter: De auteur vermeldt dat hij bij Twitter grote commentaren bovenaan bestanden plaatste om te beschrijven waar de code fundamenteel gebrekkig was, omdat het op dat moment niet rendabel was om deze fouten te herstellen, maar andere ontwikkelaars er wel van op de hoogte moesten zijn.

De "Deur"-analogie Een vriend van de auteur had een deur die alleen openging als je hem eerst stevig dichttrok en daarna pas naar buiten duwde. Omdat hij in dat huis was opgegroeid, vond hij dit volkomen normaal en "voor de hand liggend", terwijl het voor elke bezoeker onlogisch en frustrerend was. Dit is de ultieme analogie voor hoe we gewend raken aan gebreken in een systeem.

Tumblr en Moderatie De auteur reflecteert op een voormalig Tumblr-medewerker die beweerde dat Tumblr het moderatieprobleem (spam, toxiciteit) mechanisch had opgelost via het reblog-systeem. Echter, gebruikers en critici (zoals Scott Alexander in Toxoplasma Of Rage) stelden dat juist dit systeem zorgde voor een cultuur van "ragebait" en collectieve aanvallen. Om te geloven dat Tumblr moderatie had "opgelost", is een hoge mate van kwaliteitsblindheid nodig.