Mozilla Science Lab wil helpen code wetenschappers te verbeteren

Mozilla heeft via zijn Science Lab softwarecode van diverse wetenschappelijke publicaties onderzocht op kwaliteit. Daarbij hanteert Mozilla testprocedures die het ook inzet om zijn eigen code te controleren op fouten.

Wetenschappers gebruiken steeds vaker zelfgeschreven softwarecode in hun onderzoeken. Dit kan voor de nodige problemen zorgen omdat zij vaak geen weet hebben van de best practices voor het schrijven van kwalitatieve code. Niet alleen kan er fraude optreden omdat wetenschappers de broncode niet aan hun publicaties toevoegen, ook is de kans aanzienlijk dat testresultaten niet kloppen door fouten in de code.

Het Mozilla Science Lab, dat onlangs is opgericht, wil wetenschappers helpen om deze fouten in de toekomst te voorkomen, zo schrijft Nature. Daarvoor wil Mozilla dezelfde uitvoerige testprocedures inzetten die het voor zijn eigen code, bijvoorbeeld voor die van Firefox, inzet. Tijdens een eerste proef, waarbij werd samengewerkt met het wetenschappelijk tijdschrift PLoS Computational Biology, onderzocht Mozilla negen papers waarin code is gepubliceerd. De betreffende code is in diverse programmeertalen geschreven, waaronder Perl en Python.

Mozilla zou de uitkomsten met de opstellers van de papers hebben gedeeld. De uitslagen zouden geen directe impact hebben op de betreffende onderzoeken. Wel kunnen de auteurs ervoor kiezen om de conclusies van Mozilla's controle te publiceren. Daarnaast wordt verwacht dat Mozilla binnenkort een algemeen verslag over het testen van de code zal uitbrengen.

Onduidelijk is nog of wetenschappelijke publicaties in de toekomst tijdens de peer reviewing-fase ook zelf de kwaliteit van code gaan controleren, al dan niet met behulp van Mozilla's mechanismes. Hiervoor zouden extra kosten gemaakt moeten worden. Desondanks vragen sommige wetenschappers zich af of de extra controles op hun code juist het effect kunnen hebben dat er juist minder code bij onderzoeken gepubliceerd zal gaan worden.

Reacties (11)

[DwarV]

Dit is een goede zaak. Veel wetenschappelijke software (in ieder geval in mijn werkveld) wordt niet of nauwelijks getest dmv. bijvoorbeeld unit tests. De oorzaken hiervan zijn, onder andere, dat mensen die wetenschappelijke software schrijven vaak geen echte programmeurs zijn, en dat er vaak (door de publicatiedruk) geen tijd is om de software grondig te testen. Daarnaast wordt software vaak voor één specifiek onderzoek geschreven en daarna verwaarloosd. Veel van de software komt zelfs nooit in een versiecontrole systeem (zoals GitHub) terecht. Daarnaast is het vaak niet verplicht om je source code openbaar te maken bij het publiceren van een artikel, wat het controleren van andermans werk bemoeilijkt.

Kortom, er is nog veel te verbeteren in de wetenschappelijke wereld als het om software ontwikkeling gaat, maar dit is een welkome eerste stap om het bewustzijn omtrent code-kwaliteit te verbeteren onder de onderzoekers.

[Sissors]

De vraag is echter in hoeverre dit een probleem is. De code die ik zelf bijvoorbeeld gebruik is om metingen te automatiseren en om nieuwe instellingen in een chip te laden. Als je een fout in de automatische metingen hebt zitten merk je dat normaal gesproken bijzonder snel. Daarnaast doe je ook nog gewoon wat handmatige metingen en merk je het snel genoeg op als die niet overeenkomen.

En in de code die ik gebruik om nieuwe instellingen in te laden zitten standaard fouten in. Daar kom je achter omdat hij het niet doet, normaal gesproken zijn dat gewoon bitjes die op de verkeerde plek worden gezet. Daar kan je zoveel software controle algoritmes over gooien als je wilt, die komen daar nooit achter. Je komt er wel achter doordat de instelling het niet doet zoals je verwacht dat hij het doet.

Bij sommige onderzoeksvelden zal het vast nuttig zijn om de broncode openbaar te maken, maar bij veel andere is het gewoon iets dat was basisfuncties moet hebben die werken, en dat het snel genoeg duidelijk is wanneer die het niet doen. Dat je dan bug in je code hebt waardoor je door een te lange string in te tikken een bufferoverflow kan hebben is niet relevant, dat los je op door simpelweg niet die te lange string in te tikken.

[Proton_]

De gevaarlijkste code, die de meeste schade aanricht, is code die het lijkt te doen (en het subtiel fout doet).
Tests hoeven overigens niet ingewikkeld te zijn of 100% coverage te hebben om nuttig te zijn.
Een document dat beschrijft hoe de resultaten na te rekenen zijn bijvoorbeeld is al een sprong vooruit.
Het voorbeeld dat je geeft, handmatig metingen doen en die vergelijken met de uitkomst, valt ook onder testen en is 'beter dan gemiddeld'. In je publicatie kost het één zin: 'met een steekproef zijn de metingen handmatig gecontroleerd'.

[GrowMyHair]

Het 'document dat beschrijft hoe de resultaten na te rekenen zijn' wordt doorgaans wel gepubliceerd. De implementatie daarvan is vaak het bijna triviaal geachte gedeelte dat wetenschappelijk niet echt relevant is. Tenzij de vernieuwing in de implementatie zit, dan is de broncode natuurlijk reuze interessant. Anders zal code alleen bijgevoegd worden als service voor de geinteresseerde lezer die het werk na wil doen.

[Sissors]

En daarvoor moet een andere zin verwijderd worden als je al op de maximum lengte zit. Belangrijker is echter dat het totaal niks toevoegd: Het wordt daardoor niet makkelijker te controleren voor een ander, dus wat schiet je er wel mee op? Er zijn nog honderd manieren waarop je metingen fout kunnen zijn gegaan: je voegt ook niet toe dat je elke kabel hebt aangedraaid (als je toch iets hebt waar foute meetresultaten door kunnen komen), dat je meetapparatuur gecalibreerd is, dat je je voedingsspanning hebt nagemeten, etc. En het zijn toch allemaal dingen waaraan je moet voldoen om goede metingen te krijgen.

[GrowMyHair]

Klopt helemaal. Doorgaans is de computercode niet meer dan een middel om te interfacen met je hardware of je meetdata te verwerken. Je beschrijft dan de gedane metingen en gebruikte verwerkingsalgoritmes. De wetenschappelijke vernieuwing zit doorgaans niet in de Matlab, Pyton of C-code die erachter zit. De beperkte publicatieruimte ga je daar niet snel aan opofferen.
Los daarvan zijn er grote verschillen in programmeer capaciteiten van mijn collega's. Als je met iemand samen werkt is het natuurlijk fijn als er een duidelijke structuur in de code zit, deze geschikt is om makkelijk aan te passen, efficient gebruik maakt van je PC en voorzien is van voldoende commentaar. Ook om eventuele fouten te kunnen herkennen en te debuggen. Ik vrees alleen dan diegenen die niet zo goed scoren op deze kwalificaties ook niet snel de Mozilla code checker gaan gebruiken. Dat is meer iets voor mensen die toch al geinteresseerd zijn in hoe het programma geprogrammeerd is en het dan waarschijnlijk toch al netjes doen.

[Proton_]

Je opmerking versterkt het belang van de aandacht voor testen juist
Interfacen met hardware is soms moeilijk te testen (al is dat met een abstractielaag vaak ook nog wel te doen), maar juist meetdata verwerken klinkt als iets dat triviaal te unit testen is. Zonder (unit) tests die aantonen dat de gegevens juist worden verwerkt lijkt me dat alles wat uit die code komt met wantrouwen bekeken moet worden.
(Unit) tests schrijven is iets dat prima door iemand anders gedaan kan worden, hiermee komen vaak impliciete aannames mee aan het licht.

Geen tests maken == je vindt het niet belangrijk of je code doet wat je dacht.
Ik denk niet dat dat je boodschap was?

[devlaam]

Het is in principe goed dat hier iets wordt ondernomen. Ik heb bij eigen onderzoek veel gebruik
gemaakt van zelf geschreven software om berekeningen te doen, en dat
gaat maar al te snel mis. Dat was in de tijd dat unit tests nog niet waren uitgevonden,
maar een goede onderzoeker had echt wel door dat je goed moest testen. Dus dat zal
nu ook nog gebeuren, maar de systematiek ontbreekt vaak wel. Daartoe kan dit een
hulp zijn. Onze methode bestond er onder andere uit dat tenminste twee mensen aan
hetzelfde probleem werkten, onafhankelijk software schreven (en in verschillende
talen, en niet gebruik maken van dezelfde bibliotheken). Als je dan op dezelfde resultaten uitkomt zit je in elk geval in de goede richting.

Bij wetenschappelijk onderzoek gaat het erom dat je werk voor een ander reproduceerbaar is, maw
je zorgt ervoor dat je alle (noodzakelijke!) stappen om tot de resultaten te komen in
de publicatie vermeldt, maar in principe niet meer. Andere
onderzoekers herhalen vervolgens jouw werk in hun eigen lab. Krijgen ze vergelijkbare
resultaten, dan ondersteund dat weer de eerste conclusies. Ik ben van mening
dat het publiceren van eigen geschreven software daarbij niet nodig zou moeten zijn.
Een competente collega kan die software ook zelf schrijven. Dat is zelfs beter dan
gepubliceerde code gebruiken, want dan worden de fouten daarin ook hergebruikt.

Maak je gebruik van andermans software (bijvoorbeeld numerieke bibliotheken),
dan is het natuurlijk wel zaak te vermelden wat je hebt gebruikt.

Veel mensen denken dat alles wat gepubliceerd wordt ook meteen de waarheid is.
Fraude even daargelaten, dan is dat nog niet per se het geval. Het weerspiegeld
de uitkomsten van onderzoek. Pas als resultaten steeds reproduceerbaar zijn
en een goede plaats kunnen vinden in de bestaande kennis, maw, er concensus
ontstaat, kan je van 'een nieuwe waarheid' spreken. Een verkeerd antwoord
als gevolg van een bug in software veranderd niets in dat proces.

[dirkjesdirk]

Desondanks vragen sommige wetenschappers zich af of de extra controles op hun code juist het effect kunnen hebben dat er juist minder code bij onderzoeken gepubliceerd zal gaan worden.

Dat lijkt mij wel een serieus probleem. In het bronartikel staat hierover:

But researchers say that having software reviewers looking over their shoulder might backfire. “One worry I have is that, with reviews like this, scientists will be even more discouraged from publishing their code,” says biostatistician Roger Peng at the Johns Hopkins Bloomberg School of Public Health in Baltimore, Maryland. “We need to get more code out there, not improve how it looks.”

Terecht wordt er onder het bronartikel door iemand gesuggereerd dat dit valt te ondervangen door wetenschappers de mogelijkheid te bieden hun code te publiceren als een Open Source project, uiteraard met een toepasselijke licence (GPL, CeCILL, ...).

[Reactie gewijzigd door dirkjesdirk op 23 juli 2024 17:38]

[svennd]

Tests maken kost tijd, tijd die geld kost. Zowel tijd als geld is er nooit. Elke hulp is dus zeker meegenomen!

[dupy]

Weet niet wat ik hiervan vinden moet. Het is zoiets als een nog niet gepubliceerde thesis opsturen naar Microsoft voor spellingcorrectie.......