Wij maken 'null' fouten
05.01.2012
Waar software wordt gemaakt, worden fouten gemaakt, en in
elke software zitten bugs. Iedere softwareleverancier wil het graag
doen voorkomen dat de software foutloos en bugvrij is, maar
software van dat soort bestaat niet. Ook in software die al 25 jaar
succesvol wordt ingezet, kunnen nog steeds nieuwe fouten ontstaan.
Ja, ook in de software van Human Inference. De diverse afdelingen
van ons bedrijf doen er alles aan om dit te voorkomen. Voor de
supportafdeling is het zaak om daar waar dit gebeurt, de schade
zoveel mogelijk te beperken, liefst zonder dat de klant zich bewust
wordt dat er een mogelijk probleem in hun omgeving is geweest, of
wat de gevolgen hadden kunnen zijn.
HIquality bug cycle
Onze klanten zijn doorgaans erg tevreden over de implementatie en
de kwaliteit van onze software. Op de support- en
acceptatieafdeling van Human Inference krijg ik daarvan weinig mee.
Klanten bellen ons niet om te melden hoe goed alles werkt en ik heb
daar op mijn beurt ook weinig behoefte aan. Zo heb ik onze software
vooral leren kennen vanuit de problemen die onze klanten ermee
hebben, en vanuit de projecten en trajecten die minder soepel
verlopen. In bijna 15 jaar tijd heb ik heel wat soorten fouten
voorbij zien komen, zoals bugs, oneindige loops, en crashes.
Een softwarecrash is ernstig en vervelend, maar wel meteen
zichtbaar en meestal snel te repareren of te omzeilen. Veel
verraderlijker zijn die fouten, die potentieel lang en onopgemerkt
voort kunnen bestaan. Dit jaar troffen wij zo'n fout aan in ons
langst bestaande product HIquality Identify; voorheen bekend onder
de naam Intelligent Retrieval.
Identify
Met HIquality Identify worden onder meer zoekapplicaties gebouwd.
Daarbij wordt, net als bij het opsporen van criminelen door politie
en justitie, gebruik gemaakt van signalementen. Een signalement
bevat alle identificerende gegevens van een bronrecord, zoals
postcode, huisnummer, maar ook de kernwoorden die uit de plaats,
straat of persoonsnaam worden gehaald, en de fonologische codes van
die kernwoorden. Van alle relatiegegevens in een database wordt een
signalemententabel gebouwd die als basis dient voor de
zoekapplicatie. Deze benadering in het opsporen van relatiegegevens
bestaat al ruim 25 jaar, en is niet meer weg te denken.
Een signalemententabel moet up-to-date worden gehouden en
daarvoor wordt een synchronize-procedure gebruikt, die in een
databaseomgeving met triggers op de brondata wordt geïmplementeerd.
Als een bronrecord wijzigt, dan worden met deze wijziging meteen de
signalementen bijgewerkt. In dit synchronize-proces troffen we
onlangs door een melding van een van onze klanten, een boeiende,
niet te onderschatten tekortkoming aan.
Nullen, nellen en nollen
Door een foutje in de synchronize-procedure van het Oracle upgrade
pack werden NULL waarden in de database door de procedure
letterlijk als "NULL" doorgegeven. Een klein foutje met grote
gevolgen, want telkens als een record gesynchroniseerd moest worden
en één of meerdere velden waren niet ingevuld, dan werd daaruit
door de decompositiemodulen het kernwoord "null" gegenereerd. De
fonologiemodule genereerde daaruit netjes de fonologische codes
'nul', 'nel' en 'nol'.
Het eerste gevolg is functioneel van aard. Er komen naarmate er
meer gesynchroniseerd is steeds meer van dit soort waarden in de
signalemententabel, waardoor de scores licht gaan afwijken, en de
zoekresultaten minder nauwkeurig worden. In de loop der tijd gaan
signalementen steeds meer op elkaar lijken, en worden scores
onterecht steeds hoger. Een tweede gevolg op langere termijn is
meer technisch van aard. Uitgerekend de fonologische codes van
kernwoorden worden als indexering in de database gebruikt en in de
configuraties wordt om performanceredenen vooraf bepaald of een
maximum ingesteld aantal evaluaties niet wordt overschreden. Na
verloop van tijd nemen de nullen, nellen en nollen in de database
toe. Het maximum wordt nu steeds vaker overschreden, met als gevolg
dat er geen zoekresultaten meer getoond kunnen worden; in plaats
daarvan komt de melding dat er niet genoeg relevante zoekgegevens
zijn ingevoerd.
Zo kunnen slechts twee quotes in de broncode ervoor zorgen dat in
de loop der tijd; misschien wel een jaar; als een soort van
wormvirus de zoekresultaten steeds minder goed worden en
uiteindelijk niets meer opleveren.
Herstel
Twee van onze klanten hebben dit nare verschijnsel gelukkig in een
vroeg stadium kunnen traceren. Nadenkend over de mogelijke gevolgen
bij klanten die deze versie van software al langer in gebruik
hebben, brak ons het zweet hier uit. In korte tijd hebben we alle
leveringen kunnen achterhalen. Vervolgens konden we wegstrepen:
alleen het Upgrade Pack, alleen op Oracle databases, alleen deze
versienummers, en alleen als dit bepaalde productonderdeel
geïmplementeerd is. Uiteindelijk bleef er slecht een lijstje van
minder dan 10 klanten over. Bij meer dan de helft daarvan is in
dezelfde week nog een consultant op bezoek geweest voor onderhoud,
en inmiddels zijn alle foute leveringen vervangen, meestal zonder u
daar als klant iets van heeft gemerkt.
Had u dit willen weten?
Als klant wilt u dat alles naar behoren werkt en dat fouten worden
hersteld, zonder daarvan zelf alle details te moeten doorgronden.
Als er iets niet goed gaat, en als u daar last van heeft, dan wilt
u dat het wordt verbeterd. Maar wilt u ook weten welke risico's er
ooit in uw omgeving aanwezig zijn geweest?
U waarschijnlijk wel, anders had u deze alinea in dit artikel niet
bereikt. De meeste klanten beslist niet. Als u naar aanleiding van
dit artikel toch nog vragen heeft, of als u vannacht slecht slaapt
door nachtmerries over nullen, nellen en nollen in uw database,
neemt u dan gerust contact met mij op via de support afdeling van
Human Inference, waar ik mij sinds jaar en dag bezighoud met alles
wat er mogelijk mis kan gaan met onze software.
Frano Bebseler
Product Specialist
Support@humaninference.com 
Terug naar het overzicht