Softwarerot – feit of fictie?

Aan het einde van het jaar is het tijd om een ludiek verschijnsel op de korrel te nemen:
SoftwareRot. Wat zullen we nu krijgen! zie ik jullie denken. Software is geen fruit dat
zomaar kan gaan rotten. Dat is ook zo, maar SoftwareRot bestaat echt!

Het is aan het einde van het jaar een goede gelegenheid om hierover te bloggen, temeer
omdat het verschijnsel wel steeds zeldzamer wordt, maar nog steeds niet geheel is
uitgestorven..

Hoe kun je SoftwareRot zien?

We hebben hier te maken met een subtiel verschijnsel, dat slechts door nauwkeurige en
langdurige observatie is op te merken.
We kunnen er van uit gaan dat software na de oplevering nog enkele software fouten bevat.
En om die gaat het nu juist.

Wat hebben wij daarvoor nodig:

1. Software, die na in productie name niet meer ingrijpend wijzigt en waar gebruikers
mee werken;
2. Een centrale registratie van software fouten, die na de in productie name aan het licht
komen.

Elke organisatie, die ITIL gebruikt en organisaties, die goed beheer hebben ingericht houdt
dit soort fouten bij. En daarmee kun je een grafiek maken om SoftwareRot te detecteren. Wat
moet je in de grafiek opnemen: het aantal fouten dat per tijdseenheid worden gevonden. En
dat over de eerste 3 jaar na de in productie name.

Het opmerkelijke is dat de gebruikte programmeertaal geen enkele invloed blijkt te hebben
op het verschijnsel SoftwareRot.

De grafiek
De zo ontstane grafiek toont het merkwaardige verschijnsel: de grafiek toont het aantal
fouten, dat de gebruikers rapporteren over 3 jaar. In het eerste jaar worden nog wat fouten
gevonden en gefixed. Dit neemt af en we zeggen dan: de software stabiliseert. Dat klopt ook.
Zo rond het derde en vierde jaar treedt echter het verschijnsel van SoftwareRot op: de grafiek
gaat ineens en geheel onverwacht weer stijgen!

Dat is een zeer opmerkelijk verschijnsel en het wordt vaak geeneens opgemerkt omdat
bedrijven hun statistieken maar in weinig gevallen over enkele jaren heen bekijken. En ook
moet de software, die wij monitoren tussentijds niet ingrijpend zijn gewijzigd.

Wat is er nu echt aan de hand? Software is immers geen fruit en kan ook niet echt rotten..
We moeten dus verder kijken dan naar de software alleen.

Nu de meest interessante vraag: hoe ontstaat het verschijnsel?

In de eerste periode dat gebruikers met het systeem werken houden gebruikers zich vooral
aan de voorgeschreven werkwijzen en zullen daarom ook dicht bij de Use Case van het
ontwerp blijven. Na een tijd op deze manier gewerkt te hebben, zullen gebruikers eerder
geneigd zijn om te gaan experimenteren met de software. Hierdoor gaat de software op
andere manieren gebruikt worden dan zij initieel voor is ontworpen en zullen nog niet eerder
ontdekte fouten worden ontdekt.

Verder blijkt uit de praktijk dat mensen van tijd tot tijd van functie of baan veranderen.
Vroeger duurde het langer voordat er weer andere mensen met de zelfde software ging
werken, nu is dat wat korter. Ik schat dat nu in ongeveer 3 jaar de groep mensen, die met de
software werken grotendeels is ‘vernieuwd'.
Wat gebeurt er dan? De ‘eerste generatie', die model hebben gestaan voor ‘de gebruiker' zijn
vervangen door nieuwe medewerkers met nieuwe verwachtingen en inzichten. De
requirements, die op de eerste generatie was toegespitst komen niet langer overeen met de
verwachtingen van de volgende generatie. Die zullen de software ook op een andere manier
gaan gebruiken en zullen dan ook nog niet eerder ontdekte fouten gaan vinden.

Wat ook effect heeft op SoftwareRot zijn de gewijzigde behoeften van een organisatie, die nu
door licht verouderde software wordt ondersteund. Zo wordt soms een veld in de database
gebruikt voor iets waar het nooit voor bedoeld is. En dat kan in sommige gevallen leiden tot
nieuwe fouten, zonder dat de software is veranderd. Gewoonweg omdat er een potentiële fout
in heeft gezeten, die bij normaal gebruik nooit aan het licht gekomen zou zijn.

Wat kunnen wij tegen SoftwareRot doen?

Requirements: hoewel het niet gemakkelijk is kan een goede Requirements Engineer
anticiperen op toekomstig gebruik. Zoals bij voorbeeld de mogelijkheid om bepaalde
beslissingen te laten uitvoeren door een Rules Engine. Bij voorbeeld voor het bepalen of een
hypotheek verstrekt zou mogen worden. Dit kan een deel van het oneigenlijk gebruik van de
software voorkomen.

Programmeren: het is belangrijk dat de Software Engineer defensief programmeert. Dit

voorkomt potentiële fouten, die pas laat aan het licht komen.

Testen: belangrijk is ook hier het gedrag van de gebruiker op lange termijn te voorspellen en
uitgaande van dit potentieel onbedoelde gedrag te testen. Bij voorbeeld door testtechnieken
zoals Exploratory Testen en UseCase Based Exploratory Testen structureel toe te passen als
aanvulling op de meer formele en klassieke testtechnieken.

Wat betekent SoftwareRot voor organisaties?

Wordt SoftwareRot niet opgemerkt, dan wel genegeerd, dan kan dit vervelende gevolgen
hebben. Worden bij voorbeeld bepaalde database velden oneigenlijk gebruikt, dan heeft dat
zeker invloed op een latere migratie van de software. De migratie zal moeilijker zijn en meer
gaan kosten.
Organisaties kunnen het fenomeen SoftwareRot nuttig gebruiken als ‘early warning system'.

Conclusie

 SoftwareRot is een ludiek gekozen naam voor een interessant fenomeen.

 SoftwareRot bestaat echt, maar is wat anders dan je op het eerste gezicht zou
vermoeden.
 SoftwareRot is een interessante indicator om eens goed naar het gebruik van de
software te kijken.

Meer over SoftwareRot en BitRot:

 http://books.google.nl/books?
id=pjGzTOYocikC&pg=PA186&lpg=PA186&dq=softwarerot&source=bl&ots=N710
E-
oOQ9&sig=rRw7UpPktTLaDnTSmWv4SXswJiM&hl=nl&sa=X&oi=book_result&r
esnum=9&ct=result
 http://en.wikipedia.org/wiki/Software_rot
 http://www.scottpreston.com/articles/638.php
 http://www.javvin.biz/softwareglossary/SoftwareRot.html
  http://encyclopedia2.thefreedictionary.com/software+rot
 http://www.wordyard.com/2004/07/27/software-rot/
 http://ask-
leo.com/what_kind_of_maintenance_should_i_do_to_avoid_software_rot.html
 http://blogs.salon.com/0000014/2004/07/27.html