Bij Octavalent houden we netjes bij welke bugs wij ontdekken en onze klanten melden. In sommige weken zijn het er veel, andere weken zijn het er heel weinig. Maar er zijn helaas altijd wel een paar onvolkomenheden in onze software. Het drama is niet zo groot: de meeste bugs zijn binnen korte tijd en zonder al te veel moeite opgelost. En (maatwerk) software is nooit bug-vrij. Desondanks zijn fouten vervelend, vooral als eindgebruikers er mee geconfronteerd worden en daardoor hun werk niet kunnen doen.

Om het aantal bugs te verlagen heb ik gekeken naar de oorzaken. Ik kwam tot de volgende vijf oer-redenen (in willekeurige volgorde):

• Slordigheid
• Componenten van derden
• Onvolledig functioneel ontwerp
• Incorrecte technische oplossing
• Architectuur

Slordigheid

Bij bugs is er een natuurlijke neiging om de programmeur te beschuldigen. En dat klopt natuurlijk. Als je iemand de schuld zou moeten geven, dan is het degene die de software gemaakt heeft. Dit is tegelijkertijd er kort door de bocht. Software schrijven is mensenwerk, en waar mensen werken, worden fouten gemaakt. Waar gehakt wordt, vallen spaanders. Het resultaat van een individu is de resultante van zichzelf en zijn omgeving. En het blijkt dat slechts een heel klein gedeelte van de bugs toegewezen kan worden aan slordigheid, domheid of andersoortige onhandigheid van de programmeur. Althans bij ons in het bedrijf. De discipline om goed op te letten waar je mee bezig bent is hoog. En dat moeten we zo houden.

Componenten van derden

We gebruiken regelmatig componenten van derden. Voorbeelden hiervan zijn: een component om PDF-documenten te genereren, een tekstverwerker in de webbrowser, en ook de webbrowser zelf (zoals Internet Explorer of Firefox). Het blijkt dat deze componenten niet altijd foutloos zijn, waardoor onze software onderuit gaat. Dit is geen excuus. Wij kiezen de componenten en dienen goed te testen. Desondanks is het wel een oorzaak. En tegelijkertijd mogen wij er in bepaalde mate vanuit gaan dat een veelgebruikte webbrowser als Internet Explorer backwards compatible is (dat wil zeggen: wat werkt in versie 8, werkt nog steeds in versie 9). De werkelijkheid is echter anders.

Onvolledig functioneel ontwerp

Voor de ontwikkelaar aan de slag gaat wordt een functioneel ontwerp gemaakt. In dit ontwerp staat precies beschreven hoe de te ontwikkelen software moet gaan werken. Vooral bij aanpassingen aan bestaande software treden problemen op. Een voorbeeld ter illustratie. In onze software wordt na een gebruikersactie (zoals het opslaan van een product) een tekst getoond met feedback (zoals “Product ‘ABC’ is opgeslagen.”) Er waren problemen met de manier waarop deze feedback getoond wordt, dat moest anders. Anders schrijf ik expres cursief, omdat het niet duidelijk was hoe het anders moest. Dit was aan de ontwikkelaar. De ontwikkelaar in kwestie gaat hiermee aan de slag en komt met een heel mooie oplossing. Iedereen tevreden. Tot blijkt dat de feedback-teksten op bepaalde plaatsen in de software net iets anders werken dan standaard gebruikelijk is. Nu valt lang te steggelen over de vraag of dit een fout van de ontwikkelaar was, of van de ontwerper. Feit blijft dat het goed was.

Incorrecte technische oplossing

Soms wordt een technische oplossing gekozen, waarvan we zeggen: dat hadden we beter niet zo kunnen doen. Deze conclusie valt uiteen in twee varianten: a) it seemed like a good idea at the time, en b) we wisten het van te voren. De eerste variant is voor iedereen met een technisch beroep herkenbaar (toch?) En ook niet technici kunnen zich een voorstelling maken van een foutief gekozen oplossingsrichting. We weten veel, maar niet alles. We hebben geen glazen bol. En soms kiezen we een oplossing die later niet blijkt te werken. Het is erger als we van tevoren wel hadden kunnen weten dat het technisch ontwerp niet klopt. Redenen hiervoor zijn een niet eenduidige architectuur. Er zijn meerdere oplossing voor het zelfde probleem, waardoor een ontwikkelaar sneller geneigd is een geheel eigen oplossing te bedenken, die hoe briljant ook, kinderziektes heeft. Communicatie vormt hierbij een belangrijke sleutel.

Architectuur

Ieder ontworpen systeem van een bepaalde omvang heeft een architectuur. Of het nu gaat om een wolkenkrabber of een stuk software. Iemand heeft nagedacht over de vraag welke materialen gebruikt worden en hoe de verschillende structurele componenten aan elkaar vast zitten. Een winkelcentrum bouw je niet met los zand, en software hangt ook niet met elastiekjes aan elkaar. Of soms toch wel? Architectuur-bugs zijn bugs waarbij er ergens iets veranderd wordt, en daardoor ergens anders iets niet meer werkt. Een verandering in één deel van de software leidt tot problemen in een ogenschijnlijk volledig ongerelateerd ander deel. Dit soort problemen zijn onlosmakelijk verbonden met het ontwikkelen van software. Ik speel het ontwikkel-spel al enkele decennia en heb niet anders meegemaakt. Ik schaar deze bugs onder het kopje architectuur, omdat een goede architectuur kan helpen dit soort bugs te voorkomen. Bijvoorbeeld door software op te splitsen in overzichtelijk componenten. Delen die klein genoeg zijn zodat de ontwikkelaar een volledig overzicht heeft op het geheel, en niet verzuipt in meer dan 100k regels code.