Onderhoud bestaat niet…?

Zo'n twintig jaar geleden maakte Brad Cox in zijn boek: 'Object Oriented programming: an evolutionary approach' een opmerking over softwareonderhoud. Volgens hem bestaat dat helemaal niet.

Door Wim Groenendaal | Logica

Volgens Brad Cox is software niet te vergelijken met ijzer of hout. Onderhoud op software bestaat dan ook niet want software kent geen verf die kan bladderen en het kan evenmin roesten. Software hoeft ook niet te worden afgestoft of in de was te worden gezet. Ook schoonmaken is niet nodig.

Verder in zijn stelling zegt Brad: software bevat wel vaak fouten die de aandacht vragen maar dat is geen onderhoud, dat is reparatie. Hetzelfde is er aan de hand als de omgeving verandert, er is dan energie nodig om het te kunnen laten blijven functioneren. Ook dat is geen onderhoud, dit is een reparatie om het proces van veroudering tegen te gaan.

Veroudering

De vraag die bij mij opkomt, is of hij gelijk heeft… Immers het schoonmaken van software kan periodiek wel degelijk nodig zijn, denk alleen maar aan het verwijderen van dode code (instructies in de software die wel in de broncode zitten, maar nooit worden uitgevoerd).

Daarnaast is bladderen van verf of het roesten van ijzer een ouderdomsverschijnsel en ook software kent een verouderingsproces. Ook zegt hij: software hoeft niet te worden afgestoft. De periode waarin character based interfaces werden 'opgewaardeerd' tot grafische interfaces lijkt mij toch wel een aardig voorbeeld van afstoffen of in de was zetten (of misschien zelfs pimpen).

Instabiel

Echter, of we het nu onderhoud, reparatie of misschien wel verbouwing noemen, de bijverschijnselen zijn in vele gevallen hetzelfde. Ze hebben de neiging om de structuur van een applicatie te verwoesten en de wanorde binnen de applicatie te verhogen.

Naarmate de tijd verstrijkt zal er steeds minder aandacht zijn voor hoe aanpassingen binnen het oorspronkelijke ontwerp passen. Uiteindelijk wordt de applicatie instabiel doordat de structuur langzaam aan wordt verpest, zoals bij de verbouwing van een huis een dragende muur weghalen (structureel verpesten) of ruimtes herindelen met gipswandjes (langzaam aan verpesten)

Minimaliseren

Conclusie: Eigenlijk dienen we de bijeffecten van reparaties of onderhoud te minimaliseren. En om dat te bewerkstelligen moeten we kijken naar de volgende twee opties:

a) Als reparatie of onderhoud toch nodig is, gooi je alles weg en begin je helemaal opnieuw. Op deze wijze duurt het wel wat langer maar de structuur van de applicaties is altijd goed en je krijgt ook nooit legacy.
b) Je zorgt ervoor dat de architectuur van je applicatie zo flexibel is dat het de ruimte biedt voor kleine verbouwingen, reparaties of onderhoud, zonder dat de structuur er onder lijdt.

Continuïteit

Ik denk niet dat de eerste oplossing veel voorkomt. Ik ken slechts één bedrijf dat deze filosofie hanteerde en dat bedrijf is inmiddels failliet -ik weet niet of dat met elkaar te maken heeft gehad.

De tweede oplossing is moeilijker, maar biedt in elk geval continuïteit. Het is cruciaal dat men het belang beseft van een gezonde IT en software architectuur en dat het interne IT beleid er op is gericht dat in stand te houden. Daarvoor zijn leefregels nodig om te waarborgen dat het niet ontaard in een (te)grote verbouwing (denk bijvoorbeeld aan het respecteren van een bouwbesluit).

Komt het toch tot een onvermijdelijke grote verbouwing, dan moet je serieus gaan nadenken of de eerste optie niet beter is.

Wim Groenendaal is Principal IT Consultant bij Logica Management Consulting