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
Ow jeeh, dat is een moeilijke. Mag ik mij achter de volgende gevleugde uitspraak verschuilen:
Want net zoals dat Potter Stewart niet kon zeggen wat hardcore pornografie is, hij kon wel zeggen dat er een duidelijk onderscheid is tussen porno en Franse art-house films. Ik denk dat zo iets ook op gaat voor code. Als je meerdere experts vraagt of iets goed geschreven is, dan zul je misschien wel een consensus vinden, maar je zult er nooit een eenvoudige test mee kunnen schrijven.Is het dus nodig dat rechters leren programmeren? Niet per se, want als je een ziekenhuis of aannemer aanklaagt voor wantstalgelijk werk, dan hoeft de rechter ook niet te weten hoe je een badkamer metselt of een operatie uitvoert. Hij zou hoogstens goed moeten kunnen beoordelen of de getuigenverslagen accuraat zijn.
En dan moet je aannemen dat getuigen een goed verslad doen van wat ze gezien, gehoort of meegemaakt hebben. Terwijl de wetenschap beweert dat niemand, en vooral onze hersen specialist o.a. Eric Scherder, bij herhaling aantoont dat dit soort zaken per definitie door iedereen anders ervaren worden. Ga er maar aan staan.
Ik heb in het kader van aanbestedingen en overdrachten naar nieuwe onderhoudspartijen meerdere keren meegemaakt dat een forse codebase op algehele kwaliteit en onderhoudbaarheid werd beoordeeld, en dat was best goed te doen. Je ziet nooit alles, maar een totaalindruk is absoluut op te leveren. Wat het hele proces wel makkelijker maakt is als er een oorspronkelijke ontwikkelaar meekijkt, die toelichting kan geven op denkwijzes en requirements die aanleiding hebben gegeven tot structuren die op het eerste gezicht suboptimaal zijn.
Wat deze specifieke case n.m.i. echt lastig maakt, is dat het algemeen heersende beeld van code kwaliteit constant aan ontwikkeling onderhevig is. Wat we met z’n allen in 2006 nog prima code vonden, zou tegenwoordig direct afgekeurd worden. Ik zou niet meer zuiver kunnen beoordelen wat ik 10+ jaar geleden goed zou hebben gevonden. (Misschien als ik me eerst eens diep in m’n eigen archieven zou gaan inlezen?)
“Rechters moeten leren programmeren” kun je ook iets globaler proberen te zien. Als rechters meer termen leren van bijvoorbeeld programmeren, dan zou men niet manklopende analogieën hoeven te gebruiken om bepaalde concepten uit te leggen.
Ik weet niet hoe vaak dit voorkomt en hoe nodig zulke termen zijn. Maar ik kan me voorstellen dat je er moe van wordt als advocaat als je continu moet uitleggen wat een API is.
Waarbij nog maar de vraag is of de advocaat wél snapt wat ‘ie uitlegt (of reproduceert). Net als een rechter is een advocaat in basis ‘slechts’ een jurist en géén programmeur.
Is dat niet een kwestie van specialisatie?
In de advocatuur is het niet ongebruikelijk om je in een bepaald rechtsgebied te specialiseren. Letselschade, arbeidsrecht, strafrecht, familierecht, etc.
Ik kan me voorstellen dat tot op zekere hoogte dit ook zou kunnen gelden voor een rechter, alhoewel het daar minder voor de hand ligt omdat er gewoon minder rechters zijn dan advocaten en je daarmee als rechter simpelweg niet wegkomt met smalbandige specialisaties.
“de contractuele eis van ‘high quality software’?” Vraag een is dan, staat er iets over in het contract wat dat betekend. Er zijn de nodige metrics en er is research https://www.researchgate.net/publication/278786599MeasuringStructuralCodeQualityUsingMetrics Maar ook dat is iets wat je kunt gamen en daar prachtige scores in kunt halen die niet zeggen over de kwaliteit. Ik ben bang dat er in algemene zin niet veel over te zeggen is omdat een deel van de kwaliteit ook af hangt van wat de software moet doen en iets een heel mooi cijfer kan hebben maar toch niet goed mee kan bewegen met toekomstige wensen. No
plan of operationssoftware extends with any certainty beyond the first contact with themain hostile forceusers. De architectuur moet passen bij de (toekomstige) functionaliteit van de software. Komt nog bij dat er in 6 jaar een hoop kan veranderen.Dan kijk je nu naar de cutting edge van 6 jaar geleden en dan denk je meh……De combinatie van “herschrijf een programma in een andere programmeertaal” en “lever hoge kwaliteit software” is een interessante. Het vereist namelijk dat het originele programma om te beginnen al van hoge kwaliteit is. (Bagger invoer -> bagger uitvoer.) Beschikbaarheid van een goed (bijgewerkt) ontwerp van de software maakt productie van goede code een stuk makkelijker.
Ik kan op grond van de beperkte informatie die ik heb niet zeggen wat zich allemaal heeft afgespeeld en of de verwachtingen van Equihold over de resultaten gerechtvaardigd waren.
Hier is een ISO norm voor: ISO 25010. Die is redelijk objectief, maar laat wel ruimte voor flink wat interpretatie.
Onafhankelijk specialist aanstellen die het beoordeeld? Het probleem hier is dat elke partij een eigen rapport kon aanleveren. Dat moet van een derde komen om eerlijk te zijn, toch? Of denk ik nu te simpel…?
Uiteraard levert elk van de partijen een rapport aan dat hun stelling staaft. Jouw voorstel om er een derde naar te laten kijken lijkt leuk. Maar ook daar is weer een contra-expertise tegenin te brengen van weer een vierde partij (van de ene partij) en vijfde partij (van de tegenpartij). Blijft dat het voor een ieder lastig zuiver objectief te beoordelen is.
Wanneer de partijen van mening verschillen over een onderwerp waar de rechter geen verstand van heeft, kan de rechter een deskundige benoemen die hem van advies dient. (De partijen kunnen hun commentaar leveren op de vragen die aan de expert gesteld worden en voorstellen doen wie er benoemd gaat worden.) Het deskundigenrapport dient dan verder als leidraad voor de feitenbepaling.
En Bas, omdat de deskundige voor de rechtbank werkt is er geen contra-expertise; de partijen krijgen wel de gelegenheid om te reageren op het rapport.
Dank voor de toelichting. Wat ik bedoelde: er is altijd wel een partij te vinden die het tegendeel kan beweren van wat de deskundige beweert. En dat hoeft niet onwaar te zijn.
Gangbaar is dat je verwijst naar een framework om je houvast te geven, en ondertussen zelf reviews doet of laat doen (inzage in het tijdelijke product, om te kijken hoe het er voor staat). Zo’n rewrite duurt lang genoeg om daar ruimte voor in te bouwen. Bij een groot project kan je ook deelbetalingen aan die milestones hangen.
Verwijzen naar coding standards is ook gangbaar, tenslotte moet het product na levering in beheer genomen worden. Als je dat zelf doet, weet je (als het goed is) al waar code aan moet voldoen; als je het uitbesteed heeft elke propere partij waar je dat bij doet, ook guidelines.
Wat overigens ook gangbaar is, is dat als een partij code in beheer neemt, ze aanmerkingen hebben op die guidelines, en werk moeten doen om de boel ‘beheersbaar’ te maken 😉
Objectief vaststellen van softwarekwaliteit is een erg lastige. Er is veel discussie over de ins- en outs daarvan. Ik weet wel, met zo’n 30 jaar ervaring in de softwarewereld, over het algemeen vrij snel een onderbuikgevoel over een stukje code te verkrijgen — en het gaat dan inderdaad vaak om indicatoren, zoals het aanwezig zijn van zeer veel spelfouten in commentaar of naamgeving (en dan ga ik er al vanuit dat softwareontwikkelaars vaak niet Engels als moedertaal hebben, en ook nog eens regelmatig last hebben van dislexie, maar kom op, spellingscontrole is tegenwoordig in elke IDE ingebakken), het inconsistent toepassen van opmaakregels. Ik weiger dan ook om dergelijke dingen aan te pakken zonder het de onderliggende problematiek op te lossen (Ik wil mijzelf en mijn collega’s die diagnostiek niet ontnemen), en dat is het ontbreken van structuur, monolitische functies, gebrek aan decompositie en hergebruik, en meestal dan ook het totaal ontbreken van unit tests, of als die er wel zijn unit tests die voornamelijk onzin testen, met zo’n beetje alles gemocked.
Een blik in het versiecontrole en bug-tracking systeem om te zien hoe code tot stand gekomen is, is vaak ook verhelderend. Veel ad-hoc bug fixes en een slechte administratie van problemen zijn rode vlaggen. Even kijken of half-bakken oplossingen van stackexchange zijn gekopieerd zonder verstand van zaken helpt ook. (Stack exchange is prima als bron van hints, maar achterhaalde oplossingen blijven er vaak veel te lang hoog scoren.) De kwaliteit van het proces waarmee iets tot stand komt is meestal een goede indicatie van de kwaliteit van het eindproduct.
Hoe kun je dat oplossen op hoog niveau? Ten eerste zorgen dat ontwikkelaars voor lange termijn verantwoordelijk blijven voor hun product. Gebrek aan onderhoudbaarheid doet dan gewoon pijn, en eeuwige prutsers vallen dan door de mand. Consultants hebben wat dat betreft een beetje een perverse prikkel, want prutswerk, in de vorm van slecht onderhoudbare code levert gewoon meer uren op het factuurtje op. (Ik zeg niet dat dat geldt voor alle consultants, en regelmatige zorgen consultants juist voor een goede kruisbestuiving van goede ideeen, omdat ze in meerdere toko’s mee kunnen kijken). Software ontwikkeling is voor veel bedrijven toch echt core business, en dan moet je naar mijn mening gewoon een core team van eigen ontwikkelaars in dienst hebben, die de vinger aan de pols houden, en dus meedraaien, mee-reviewen, en meedenken met externe partijen.
Je kunt een bepaald niveau van unit testen en code metrics (als gemeten door tools als SonarQube of JaCoCo) contractueel afspreken, maar dan komt het oude adagium “you get wat you pay for” weer om de hoek kijken, of verhuist de problematiek zich naar een architectureel niveau, waar je er met prima code coverage en perfect groene vlaggetjes in sonar er alsnog een zooitje van kunt maken.
Ik maak en maakte in bijvoorbeeld variabelennamen juist vaak expres Engelse spelfouten. Moet ik bijvoorbeeld bijhouden hoeveel bytes of regels er al gelezen zijn, dan wil ik zo’n variabele nog wel eens
rednoemen, en liever nietreadomdat dat in C een system call is én het verkeerd gelezen kan worden in het Engels (lezen of las/gelezen?).Is dat niet goed?
Wat bedoel je met dat laatste woord?
mocken is het vervangen van onderliggende libraries door “stubs” of test versies van die library, zodat je kunt testen hoe code reageerd op dingen die van een service die je gebruikt komen, zonder dat je die hele service hoeft op te tuigen, en met de mogelijk ook allerlei zeldzame fout-condities te genereren. Je moet natuurlijk nooit de “code under test” zelf mocken (en dat heb ik echt gezien), want dan is je test niets meer waard.
Ikzelf vermijd liever te generieke namen, als read al een systemcall is, dan is een andere globale functie of variable met de naam red (tevens een kleur!) verwarrend; ik zou in jouw scenario gaan voor bytesRead of linesRead, waarmee gelijk ook de eenheid expliciet is gemaakt.
Nee, noem het dan readCount of read_count, of voor mijn part i.
bytesRead or linesRead lijkt me nog beter leesbaar 🙂 Vaak een van de moeilijkste dingen. Goede namen. Voordeel wel dat we tegenwoordig niet meer op ponskaarten zitten te tikken dus wat meer ruimte hebben voor SecondaryCitizenshipCountryCode ipv SecCitCC of strSCCC
Ja, jullie hebben gelijk.
Ik kan als IT’er wel een gooi ernaar doen maar is geenszins compleet:
Hoe zijn de variabelen en subroutines genoemd in code. Sub routine dfv(int ye) of setDisplayCode(int theWidth).
Zijn alle rand gevallen van subroutines getest en de uitkomsten van die testen beschikbaar.
Hoeveel tijd is een programmeur gemiddeld kwijt aan de aanpassingen in het softwarepakket als deze zonder voorkennis van dit specifieke pakket aan de slag moet.
Ruim boven verwachting.
Is er een gangbare taal gebruikt waar makkelijk personeel voor te werven is (in dit geval is het antwoord ja).
Bovenstaande is natuurlijk lang niet compleet, maar geeft wel een idee hoe je zoiets zou moeten aanpakken juridisch gezien.
Naar mijn mening moet je niet sec bij de code zelf beginnen. Laat de uitvoerende partij eerst maar eens met een vooraf geschreven ontwerpdocument komen waarin is vastgelegd wat de klant wil, wat de software zou moeten doen/kunnen, en op basis daarvan hoe in grote lijnen de structuur van de software er uit zou moeten zien. Zelfs voor, voor de buitenwereld, zeer complexe software kan je letterlijk in 10 A4-tjes al een goed overzicht schetsen van de ‘gelaagdheid’ en opzet van die software, hoe bijvoorbeeld de GUI er in grote lijnen uit gaat zien, communicatie tussen eventuele server/clients, hoe de datastructuren worden opgezet/onderverdeeld en beheerd, hoe libraries worden onderverdeeld plus al hun onderlinge samenhang. Dat is al ruim voldoende om een goed framework in code op te kunnen zetten, en aan de invulling daarvan kan je vervolgens zien of er een prutser aan het werk is geweest of niet. En als zo’n document ontbreekt of als zwaar onvoldoende wordt beoordeeld, dan hoef je niet eens aan de code te beginnen.
Lees ook eens op Geenstijl de serie ‘UWV, kroniek van een faalfabriek’ en je valt letterlijk van je stoel waar dit soort grote softwareboeren mee weg weten te komen. Dus nee, heel positief sta ik daar niet in…
En hoe en door wie wordt in dit geval geoordeeld over de kwaliteit van de documentatie? Ook daarvoor zal een rechter niet voldoende technische know how hebben. Ook dan moet een ander (expert) dat doen. En op basis van welke maatstaven?
Ik beschrijf alleen het traject wat kan worden gevolgd voordat in detail naar de code wordt gekeken, en uiteraard laat je zoiets door een expert doen. Als het document ontbreekt of zelfs niet aan de criteria voldoet die je een eerstejaars student zou opleggen, dan heb je verder geen maatstaven nodig en misschien zelfs geen expert. Kijk eerst maar eens wat er ter tafel komt, daarna kan je een afweging maken hoe, door wie, en op basis van welke criteria je de beoordeling verder gaat doen.
Eens, het traject er om heen is belangrijker. De broncode is minder relevant dan het basisontwerp.
Kom eerst eens met goed vastgelegde duidelijke structuur van herkenbare functies. Een hap snap Agile aanpak van code gaan kloppen en dan zien of het iets begrijpelijks wordt is het hutje bouwen van restmateriaal. Het zal geen gedegen duurzaam bouwwerk opleveren. Bouwtekeningen met een doorberekening van onderdelen zou een norm horen te zijn. Altijd leuk de mythical man month. Je kunt ook terug naar de verslaglegging van de softwarecrisis gehouden in 1969 waar E.Dijkstra aanwezig was.
Allebei deze statements kunnen tegelijk waar zijn. De software-markt is nogal dramatisch, wat dat betreft.
Dat klopt, er wordt altijd onderhoudbaarheid als eis gesteld. De veranderingen gaan vaak zo snel dat men de functionele eisen vaak vergeet en hoopt die terug te kunnen lezen door naar code te gaan kijken.
Is het marktconform dat software “High Quality” software is? Dat lijkt me niet; een opmerking als “high quality” zou juist moeten betekenen dat het beter is dan “marktconform”. Ik interpreteer marktconform hier dan als “gemiddeld”, of “modaal”, beide in elk geval minder van kwaliteit dan “high quality”.
De beoordeling van broncode hangt volgens mij af van het software ontwerp. En hoe complexer het systeem, hoe belangrijker het ontwerp is. Toen ik ruim 25 jaar geleden startte in de ICT heeft mijn werkgever me eerst naar Volmac Toptraining (by the way – later overgenomen door Capgemini) gestuurd om gestructureerd ontwerpen & programmeren te leren voordat ik aan de slag mocht. Dat was een grondige en harde leerschool. Maar de aanpak en maatstaven van toen zijn nog steeds relevant bij het beoordelen van software.
Volgens het rapport van de klant is de kwaliteit (ver) onder de maat. Volgens het rapport van de ontwikkelaar is de kwaliteit marktconform. Op basis van mijn eigen ervaring, lijkt het me waarschijnlijk dat beide gelijk hebben. Marktconforme software heeft over het algemeen een zeer lage kwaliteit.
Misschien is de vraag dus niet zo zeer wat de objectieve kwaliteit van de software is. Want daar is inderdaad veel (wetenschappelijk) onderzoek naar gedaan en zijn goede methodes voor om dat vast te stellen. Er zijn een aantal bedrijven die dit soort assessments doen. Zoals bijvoorbeeld de Nederlandse Software Improvement Group.
Een betere vraag is wellicht: wat mag een klant verwachten van de kwaliteit van software? En dat is een stuk lastiger. Want softwareontwikkeling is een relatief jong vakgebied, waarbij, helaas, er nog niet echt een standaard of norm is ontstaan voor wat ‘goed’ genoemd mag worden. Het lijkt me dan ook ondoenlijk voor een rechter hier een uitspraak over te doen.
Misschien kan de IT in deze iets leren van andere disciplines waar goed en fout niet zwart-wit is. Zowel de geneeskunde als de advocatuur kennen tuchtrecht. Misschien zou zoiets ook passen in de IT. Probleem daarbij is wel dat IT vaker een groepsprestatie is, dan een individuele prestatie (al heb ik het idee dat dat tegenwoordig voor de geneeskunde en advocatuur ook geld). En verder kan iedereen een IT-bedrijf beginnen of zich aanbieden als softwareontwikkelaar. Een diploma in de Informatica is daarvoor niet nodig. Dus wat voor sanctie zou het IT-tuchtrecht dan op kunnen leggen?
De trend in de industrie naar Agile is, mijns inziens, mede ingezet om vaker en sneller in te kunnen grijpen als de leverancier niet aan de verwachtingen voldoet. In plaats van na 5 jaar, wat hier het geval lijkt te zijn geweest, erachter te komen dat de software niet voldoet, is hij Agile het idee dat je hier al na weken of hooguit maanden achter komt. Maar voor Agile om succesvol te zijn is ook IT-expertise bij de klant vereist. En lang niet alle klanten hebben voldoende expertise om de output van een Agile ontwikkeling te kunnen beoordelen.
Als een klant die expertise niet heeft zou is het wellicht niet verstandig om zelf software te laten maken. In plaats daarvan zou ik een klant adviseren om een service af te nemen bij een dienstverlener. Als daar dan software voor nodig is dat is het aan de dienstverlener om de kwaliteit daarvan te garanderen. De klant kan dan afspraken maken met de dienstverlener over de kwaliteit van de geleverde dienst. Iets waarvan, over het algemeen, wel objectief en voor de rechter te bepalen valt of aan de gemaakte afspraken voldaan is.
Echter de hier beschreven case stamt uit 2005. Ver voor zowel Agile als IT als service gemeengoed was.
Wat me opvalt is dat men vooral focust op de architectuur, opzet en onderhoudbaarheid, niet over de bugs en problemen tijdens het daadwerkelijke gebruik van de software. Die waren er zo te lezen ook.
“Het werkt niet” is volgens mij een stuk eenvoudigere discussie als “het is niet zo mooi gemaakt”.
Misschien wel makkelijker, maar het een is vaak wel een gevolg van het ander; en als je het dan wel werkend wil maken, is een goede opzet echt een verschil van dag en nacht. Een bugje is te vergeven, broncode die eruit ziet als een ouderwetse autosloperij niet.
Natuurlijk. Mijn punt is: indien er sprake is van zowel een enorme hoeveelheid bugs, en een slechte onderhoudbaarheid, dan is het eenvoudiger om de bugs aan te grijpen om te klagen.
Er was niet enkel “een bugje”, partij claimt klanten te zijn kwijtgeraakt doordat de software zo slecht was.
Fowler refactoring van code. Het is opschonen van code om onlogische constructies er uit te halen, de boel beter te structureren. Het is een inspanning die ogenschijnlijk niets opbrengt omdat de functionaliteit niet wijzigt. Pas als de code schoon genoeg is (een goede nette structuur heeft) is het verstandig to uitbreiden van functionaliteit over te gaan. Die je beiden tegelijkertijd … de spaghetti tijd, tegenwoordig pizza’s.
Maar refactoring leidt dan tot een kip-ei probleem: om veilig te kunnen refactoren heb je al redelijk gestructureerde code nodig, afgedekt met goede unit tests, maar om unit tests bij rommelcode toe te voegen moet je deze eerst refactoren… je zult jezelf aan je haren uit het moeras moeten trekken, als het ware.
Klopt, je zegt ook redelijk en dan kan dat nog beter gedaan worden. Gebruik voor die verbetering de bestaande unit en regressietesten zodat de functionaliteit niet veranderd enkel de code strcutuur. Nieuwe stubs op plekken waar een bedachte interface moet gaan komen kun je er al inbouwen.
Heb je rommelcode en geen unit en geen regressietest dan zul je met de testen moeten beginnen en de rommelcode langzaam aan goed zien te krijgen. Aan het je onttrekken uit een moeras is een lastige opgave.
Ik heb een tijdje in een club gezeten die dit soort onderzoeken deed. Het was leuk om te doen. Je kreeg dan, zeg, 2 miljoen regels code, een week tijd, en de vraag “Is dit goede software”? Met die middelen en in die tijd kun je standaardtechnieken toepassen om te beoordelen of er netjes gewerkt is: je kijkt of de zaak netjes is gemodulariseerd, of de onderdelen zinvolle namen hebben, of er veel dubbele code voorkomt, of het aantal afhankelijkheden tussen de onderdelen beperkt is en een logische structuur heeft, en zo nog wat meer. Wat je daarmee vindt zegt wat over de onderhoudbaarheid van de code, maar niet alles: als bijvoorbeeld de software volledig afhankelijk is van niet meer ondersteunde software van anderen, en je je eigen spul om die reden van scratch af opnieuw moet maken, zegt zo’n onderzoek daar niets over. Het zegt niet of de gekozen opbouw of middelen goed gekozen zijn, en nog steeds goed geschikt zijn, voor het beoogde doel. Het zegt ook niets over wat de software doet, laat staan of de software goed werkt. Het zegt al helemaal niet over of de software zijn geld waard is – want er wordt niet bij verteld of het allemaal in een vloek en een zucht gedaan moest worden door mensen die nul verstand hadden van programmeren of van het op te lossen probleem. Je kunt naar al die dingen natuurlijk ook onderzoek doen, maar dat is allemaal veel specialistischer werk, er zijn geen garanties dat je de benodigde info in een redelijke termijn boven tafel krijgt, en de resultaten zijn moeilijk objectief te maken – het is niet goed langs een meetlat te leggen. Meestal beperkten we ons dus tot ons standaardonderzoek dat keek of er netjes gewerkt was, wat iets zegt over de onderhoudbaarheid. Dat vertelden we er ook eerlijk bij. Ik verwacht dat SQMI hetzelfde doet. Ze doen blijkbaar ook uitspraken over hoeveel werk het naar verwachting gaat zijn om die onderhoudbaarheid op orde te krijgen. Dat lijkt me prima te doen, als je onderzoek op dit gebied hebt gedaan en veel cijfers hebt gezien over de kosten van softwareontwikkeling in de praktijk. Maar dat zegt dus weinig over hoe belangrijk die onderhoudbaarheid in de gegeven situatie is en in hoeverre die je in de gegeven situatie redelijkerwijs mocht verwachten – daarvoor moet je andere factoren meetellen. Laat staan dat het je een totaaloordeel geeft over de kwaliteit van de software.
Het is wel eens voorgekomen dat we een standaard onderhoudbaarheidsonderzoek hadden beloofd, ik zag aankomen dat dat de gestelde vraag totaal niet ging beantwoorden, en ik dan ging improviseren en een alternatief plan bedenken om in dezelfde tijd een veel nuttiger resultaat te kunnen behalen – liever iets nuttigs dan iets meetbaars, vond ik. Of we deden een simpel standaard onderzoekje plus ad hoc extra werk. Meestal is een standaard onderhoudbaarheidsonderzoek een noodzakelijke eerste stap om de vraag of er kwaliteit is geleverd echt goed te kunnen beantwoorden.
Wat mij dus, net als jou blijkbaar, vooral interesseert is in hoeverre hier wordt gekeken of de opdrachtgever wel realistische verwachtingen heeft over de mogelijkheden en beperkingen van zo’n onderzoek.
Een expert die verklaard dat je beter alles opnieuw kan schrijven neem ik al niet al te serieus, als het in die jaren gewoon in productie is geweest is het zeer zelden een goed idee om helemaal opnieuw te beginnen.
Verder zei Sander het hierboven al. In de afgelopen 20 jaar is er heel veel gebeurd en veranderd op het gebied van software ontwikkeling. Met de ogen van nu kijken naar software wat toen is ontwikkeld is niet heel fair. We beoordelen de eerste iPhone ook niet in verhouding met de huidige phones.
Ik zou zeggen: 1) als een tool als “lint” zegt dat het goed is: “lint, or a linter, is a static code analysis tool used to flag programming errors, bugs, stylistic errors, and suspicious constructs” 2) als al je unittests slagen Wel vantevoren vastleggen. Niet na afloop of na 10 jaar aankomen met die eis.
Metrieken zeggen zeker niet alles: op code-niveau kan alles best aardig zijn, maar het kan op de architectuur gewoon fout zijn door verkeerde keuzes. Naar mijn mening moet je vooraf gaaan bespreken wat “onderhoudbaarheid” nu echt betekent. Voorziet men decennia van alleen bugfixing, of is het een partij waarbij men het product als een startpunt ziet van decennia functionele uitbreiding? Beide vallen onder het kopje onderhoudbaarheid, maar vereisen wel totaal andere voorzieningen tijdens bouw en exploitatie. Toen ik zelf dit soort onderzoeken deed, was dat dus de eerste vraag: in wat voor toekomstscenario’s moet de onderhoudbaarheid in voorzien? Want elke architectuur kent zijn grenzen, en als er vooraf geen afspraken zijn over waar die grens redelijkerwijs ligt, dan heb je een probleem. Probleem is dat post-project, zonder afspraken, beide partijen perfect feitelijk gelijk kunnen hebben als het gaat over hun beeld van de onderhoudbaarheid, maar het toch oneens kunnen zijn. Het product is wat het is, als de toekomstvisie anders is, kun je het alsnog grondig oneens zijn.