Deskundige vereist voor beoordeling gebrekkige broncode, meldde ITenRecht onlangs. In een automatiseringsgeschil tussen softwareontwikkelaar Capgemini en haar klant Equihold (die de software wilde inzetten bij onder meer FC Barcelona) ontstond discussie over de kwaliteit van de tot dan toe gemaakte broncode. Een mooi voorbeeld van hoe de rechtspraak omgaat met inhoudelijk diepgaande issues. Ik las laatst weer dat rechters moeten leren programmeren omdat ze anders dit soort zaken niet kunnen doen. Onzin, wat mij betreft. Daar heb je deskundigen voor. Maar bij deze zaak denk ik dan wel, blij dat ik die deskundige niet ben.
In 2002 ontwikkelde Equihold een sportapplicatie met de naam 1-2 Focus. Deze applicatie was geschreven in de programmeeromgeving en programmeertaal VB6. In 2004 besloot men deze om te werken naar Microsoft .NET, waarna men in 2005 een raamovereenkomst sloot met Capgemini om het werk te laten doen. Ik zal u de verdere tijdlijn besparen, maar in 2010 eindigde het feest met een brief aan Capgemini met als titel “1-2Focus; developed by Capgemini A Showcase of Bad Practices”.
Wat was er nu precies aan de hand met die broncode? Helaas is dat in het arrest niet in detail te achterhalen. We moeten het doen met uitspraken als
Capgemini kon daar echter een ander rapport tegenover stellen dat juist aantoont dat de onderhoudbaarheid marktconform is.Volgens [B] , een voormalig werknemer van Equihold, heeft de broncode niet de gewenste laagstructuur, bestaat deze uit onnodig veel regels en is deze onsamenhangend. Zijn conclusie is dat de broncode van zo bedroevende kwaliteit is dat het volledig herschrijven daarvan onvermijdelijk is. SQMI is volgens [appellant] een gerenommeerde en onafhankelijke partij die een onderzoeksmethode gebruikt die is ontwikkeld door het Institute for Software Quality (IfSQ). Het rapport SQMI concludeert dat de broncode een hoog aantal ‘defect indicators’ heeft, dat de onderhoudskosten van de software onnodig hoog zijn en dat de software ongeschikt is als platform voor verdere ontwikkeling. Graham Bolton, oprichter van IfSQ en directeur van SQMI, (verder Bolton) voegt daar in een schriftelijke verklaring aan toe dat het verbeteren van de geconstateerde gebreken meerdere jaren in beslag zou nemen, en zelfs meer tijd zou kosten dan het geheel opnieuw schrijven van de applicatie.
Dan krijg je dus de situatie dat partijen elkaar tegenspreken, en dat je als rechter dan moet vaststellen wat er nu waar is. In een geval als dit is dat erg lastig, allereerst natuurlijk omdat broncode op kwaliteit toetsen sowieso ingewikkeld is (de een z’n ***var is de ander z’n nachtmerrie) maar ten tweede omdat dit om zo’n grote codebase gaat dat er een hele partij werk in gaat zitten. Oh ja, en omdat er natuurlijk niet echt objectieve standaarden zijn om codekwaliteit vast te stellen.
Een belangrijke factor in het geschil was de onderhoudbaarheid: kun je op lange termijn hiermee door, ook (denk ik) met een andere onderhoudspartij dan Capgemini zelf. Bij grote applicaties is langdurig gebruik te verwachten, dan heb je andere verwachtingen qua onderhoud en aanpasbaarheid voor de toekomst dan bij een snelle app voor een event begin volgend jaar.
Dus, ik gooi hem eens in de groep, voor al die IT-ers die denken dat rechters meer verstand van software nodig hebben: hoe zouden jullie bij deze berg aan code objectief vaststellen of de kwaliteit voldoet aan de contractuele eis van ‘high quality software’?
Arnoud