overpeinzingen

Computerinfrastructuur die op universiteiten wordt gebruikt, maakt geen deel uit van een markt, laat staan van een "transparante markt" waarin iedereen een duidelijk zicht heeft op de alternatieven die er zijn en wat hun relatieve baten en kosten zijn.

Niemand in een universitaire onderzoeksgroep vindt het vreemd om te betalen voor pennen en papier.

Niemand in een onderzoeksgroep vindt het vreemd om te betalen voor ultramoderne laboratoriumapparatuur.

Maar heel vaak worden computerdiensten gratis aangeboden. Net als water en elektriciteit zijn ze verdisconteerd in de algemene kosten van het runnen van de universiteit.

Deze situatie is onhoudbaar in een wereld waarin biowetenschappelijk onderzoek wordt gedreven door big data. En het wordt ook onhoudbaar in een wereld waar grote opslag- en computerinfrastructuur die geschikt is voor routineklussen, commercieel kan worden gehuurd.

De duurzame weg naar de toekomst is een goed budget voor gegevensverwerking en -opslag. Budgettering voor computerbehoeften betekent dat mensen kosten en baten moeten afwegen, zoals bij elk ander aspect van een onderzoeksproject.

Photo: CC-BY-SA-NC on Flickr by John Flinchbaugh

Dit is een van de syndromen die we proberen te bestrijden in BioAssist...

Als je ooit aan projectplanning hebt gedaan zou je kunnen weten dat Douglas Hofstadter, in zijn boek Gödel, Escher, Back, een belangrijke wetmatigheid heeft geformuleerd die De Wet van Hofstadterheet:

Alles duurt langer dan je denkt, zelfs als je rekening houdt met de Wet van Hofstadter

In de praktijk is deze recursieve wet heel lastig te gebruiken. Ik gebruik meestal een niet-recursieve variant, die ook rekening houdt met de planning van een project:

Een zorgvuldig gepland ontwikkelingsproject duurt π keer langer dan je denkt. Als je niet zorgvuldig plant, wordt dit π²

Het programmeerwerk dat we in ons team kiezen, is als de hals in de zandloper die life science-onderzoek en -technologie vertegenwoordigt:

• Er zijn veel zandkorrels boven ons. Die vertegenwoordigen alle softwaretools die zijn ontwikkeld in life science-onderzoek.
• Beneden ons is een grote leegte. Dit vertegenwoordigt de behoefte aan breed toepasbare tools in de life sciences.
• Op de bodem liggen ook zandkorrels. Ze zijn goed geregeld. Deze vertegenwoordigen de huidige technologie: commercieel verkrijgbare tools en goed onderhouden open source-pakketten.

Hoe komt het zand van boven naar beneden? Via de ontwikkelingshals. Het is smal; slechts enkele academische tools halen de bodem. De stroom door de nek wordt aangedreven door:

• push: enkele academische groepen die de mogelijkheid en capaciteit hebben om hun tools beschikbaar te stellen
• pull: een paar bedrijven die ver vooruit kijken en de potentie van een academische tool zien en benutten

Mijn moedertaal is Nederlands. Die van mijn vrouw is Frans. We spreken elkaars taal allebei vloeiend. Maar we hebben elkaar oorspronkelijk in Duitsland ontmoet en hebben altijd samen Engels gesproken.

Een softwaregroep als de onze moet leveren wat klanten willen... maar dat kan lastig zijn, omdat ze vaak niet vragen wat ze willen. Dit komt omdat klanten denken te weten wat een probleem veroorzaakt en ze denken te weten wat de beste manier is om het probleem op te lossen. Vervolgens formuleren ze hun verzoek langs die gedachtenlijn in een poging ons te helpen.

Een voorbeeld: ik had eens klanten die me vroegen of ik mijn software zo kon veranderen dat het de getallen zou afronden die het zou gebruiken om een robot te positioneren. Het zou gemakkelijk zijn geweest om aan dat verzoek te voldoen, maar ik besloot te vragen waarom? Dit bleek een goed idee. Ik ontdekte dat de klanten de nummers kopieerden naar een ander softwarepakket. In plaats van te doen wat de klanten vroegen, schreef ik uiteindelijk een directe interface naar de andere software. Dit maakte het leven van de gebruikers nog veel gemakkelijker, zonder de mogelijkheden van de robot te beperken.

We kunnen klanten niet kwalijk nemen dat ze niet weten wat makkelijk en wat moeilijk te implementeren is. Beide kanten. Ze kunnen denken dat iets heel gemakkelijk is, terwijl het in feite heel moeilijk is. Maar het komt ook voor dat ze een vraag niet durven te stellen waarvan ze denken dat die moeilijk is, terwijl die in feite heel makkelijk te implementeren zou zijn.

Als je de best mogelijke software wilt maken, moet je blijven vragen "waarom" totdat je gebruikersrapport is gewijzigd in "Als ik A doe, krijg ik B. Maar in plaats van B zou ik C willen zien (omdat ik D nodig heb )". Dit zal u helpen beslissen hoe de klanttevredenheid kan worden gemaximaliseerd. Het maximum kan veel hoger zijn dan uw klanten verwachten.

Ja!

Er is een interessant verschil tussen hoe risico's vaak worden benaderd in een onderzoekslaboratorium waar veel gegevens worden verwerkt en in een chemisch laboratorium. Veel mensen die met data werken, lopen regelmatig tegen problemen aan, zoals het niet snel kunnen vinden van data of het niet exact kunnen reproduceren van resultaten, maar denken ze vaak dat deze problemen een integraal gevolg zijn van het werken met grote hoeveelheden data en herkennen ze deze problemen niet als problemen met de datamanagementpraktijk en -voorbereiding. Het equivalent in een chemisch laboratorium zou zijn dat onderzoekers denken dat dagelijkse branden en explosies van nature horen bij het werken met chemische verbindingen, in plaats van deze te erkennen als een gevolg van slechte laboratoriumpraktijken en slechte voorbereiding.

Ook is er weerstand tegen de invoering van een datamanagementspecialisme omdat veel onderzoekers denken dat datamanagement relatief eenvoudig is. Iedereen heeft thuis een computer en velen houden fotobibliotheken bij. Deze ervaring vertaalt zich echter niet direct in het kunnen werken met grote hoeveelheden data in een lab:

• Gegevens in het lab zijn vaak 1-3 ordes van grootte groter dan een fotobibliotheek thuis. Een onderhoudsklus die een uur kost voor fotobibliotheek zou zich vertalen in meer dan 6 maanden werk in een groot data-intensief project. Hierdoor is er echt behoefte aan andere benaderingen.
• Gegevens in een fotobibliotheek bestaan uit JPG-bestanden en misschien RAW-bestanden, en deze bestanden hebben eenvoudige 1-op-1-relaties. In het lab zijn er veel meer verschillende soorten data en de relaties zijn veel complexer.
• Een fotobibliotheek wordt meestal door één persoon onderhouden. In het lab wordt door verschillende mensen aan dezelfde data gewerkt, en ze moeten allemaal op de hoogte zijn van alles wat de anderen doen.

En inderdaad, zelfs in een fototheek thuis kan men niet altijd even snel vinden wat men zoekt.

Als je geen gebruikersfeedback krijgt voor je software, zijn er twee mogelijke redenen.

1. Het is slecht. Niemand gebruikt het.
2. Het is goed. Iedereen is blij.

Als dit je overkomt, denk dan eens terug. Heb je al eerder feedback gekregen? Hoe reageerde je?

• Heb je naar je gebruikers geluisterd en hun problemen opgelost?
• Heb je je gebruikers verteld hoe je vindt dat de software moet worden gebruikt?

Door deze twee vragen te beantwoorden kun je zelf uitzoeken waarom je geen feedback meer krijgt. Als je hebt geluisterd en de stroom vragen is gestopt, betekent dit waarschijnlijk dat de gebruikers nu tevreden zijn. Als je hebt geprobeerd het gebruik te corrigeren, gebruikt waarschijnlijk niemand het meer.

Je bent toch niet vergeten je contactgegevens te vermelden?

Nadenkend over Poisson-statistieken vroeg ik me af hoeveel nut een klok zou hebben die de seconden zou tellen met telstatistiek ofwel Poisson-statistiek. Dat wil zeggen: een klok met de onregelmatigheid van radioactief verval. Sommige mensen zetten hun horloge een paar minuten voor op de werkelijke tijd om er zeker van te zijn dat ze nooit te laat zijn, maar het probleem is dat ze daar na een tijdje op kunnen gaan rekenen. Een echte willekeurige klok kan zo onbetrouwbaar zijn dat je altijd voorzichtig voor moet blijven lopen….

Bij de RAMIRI-training (Realising and Managing International Research Infrastructure) die ik deze week in Triëst volgde, sprak één zin mij bijzonder aan. Deze was van Kimo Koski (CSC Finland) die opmerkte dat het moeite kost om een organisatie klantgericht te houden terwijl deze groeit.

Vanaf ongeveer 100 mensen kan een organisatie zichzelf volledig bezig houden zonder ooit een klant te bedienen.

Toen ik voor Bruker AXS werkte, zei onze verkoopdirecteur Paul Ulrich Pennartz soms iets verwants als hij in een cynische bui was:

Zonder die vervelende klanten zouden we ons eindelijk kunnen concentreren op ons werk.

Als je je ooit hebt afgevraagd waarom kleine bedrijven sneller reageren dan grote, dan denk ik dat deze twee mensen de oorzaak vrij goed samenvatten.

(noot: dit is de essentie van wat deze beiden gezegd hebben, dit waren niet hun letterlijke woorden)

Als er meer dan één taak moet worden voltooid, is het altijd beter om de ene voor de andere te doen. Dat besprak ik eerder in de post Parallelle processen in een projectteam.

Een individuele klant met een nieuwe vraag zou kunnen denken dat het nog sneller gaat als je zijn project ertussen inpast. We moeten die klanten ervan bewust maken dat als we onderbrekingen van welke aard dan ook toestaan in een agile sprint, niets ooit zal worden afgemaakt. Wat kunnen we ze vertellen? Er zullen andere mensen zijn met nieuwe verzoeken terwijl we aan uw taak werken.... moeten we ook hun verzoeken honoreren om ons werk te onderbreken?

Ze moeten begrijpen: agile sprints worden niet onderbroken. Ze worden voltooid of geannuleerd.

Image from Flickr by brittgow

Hoe belangrijk is het om prioriteiten te stellen?

Laten we aannemen dat we 4 ideale projecten A, B, C, D en een ideaal projectteam hebben. Elk van deze projecten neemt 3 maanden in beslag. Ze zijn allemaal even belangrijk. We werken er parallel aan. Wanneer zijn de projecten klaar? Project A is na 12 maanden klaar. Project B is na 12 maanden klaar. Project C is na 12 maanden klaar. Project D is na 12 maanden klaar. 

Wat gebeurt er als we prioriteiten stellen en aan de projecten in alfabetische volgorde werken? Wanneer zijn de projecten nu klaar? Project A is na 3 maanden klaar. Project B is na 6 maanden klaar. Project C is na 9 maanden klaar. En project D is na 12 maanden klaar. Iedereen behalve de klant van project D wordt er beter van! Fantastisch, toch?

Helaas is dit niet de perceptie van de klanten. Elk van hen ziet een project van 3 maanden en wil het in 3 maanden af hebben. De klant in project D wil niet horen "we gaan over 9 maanden aan je project beginnen". Prioriteiten veranderen daarom maar al te vaak. Elke maand, tijdens een evaluatie van het projectteam, zul je gedwongen worden om nieuwe prioriteiten te stellen. Wat is het effect? Project A is na 9 maanden klaar. Project B is na 10 maanden gereed. Project C is na 11 maanden klaar. Project D zal na 12 maanden klaar zijn.

Wat een verspilling. Trap niet in deze val. Stel prioriteiten en blijf bij de keuze.

[Afbeelding: goldstardeputy]

Na elke ingrijpende verandering in een organisatie is er behoefte aan een fase van rustige doordachte verbeteringen. Wonderen verwachten van enorme bedrijfsreorganisaties is een misvatting die leidt tot reorganisatie na reorganisatie, mogelijk resulterend in volledige vernietiging van de organisatie.

Heb je ooit een spelletje Pac-man gespeeld? Het is een eenvoudig spel waarbij je een kleine figuur bestuurt die stippen op het scherm eet, terwijl geesten je achtervolgen. De game is een uitstekende spiegel van het zakenleven in een veranderende omgeving:

• In Pac-man probeer je bij elke stap je gezondheid te verbeteren door een stip te eten en uit de buurt van de geesten te blijven.
• In het zakenleven brengt u kleine wijzigingen aan in uw producten en procedures om meer te verkopen en uw concurrenten uit de weg te blijven.

Er is nog een analogie:

• In Pac-man lopen dingen soms vast. Geesten komen van alle kanten dichterbij en er is geen ontkomen aan. Op zo'n moment kun je gebruik maken van de teleport: een paniektoets die je in een oogwenk naar een willekeurige plek in de scene brengt.
• In het zakenleven loopt het soms vast. Concurrenten komen dichterbij en het lijkt erop dat er geen uitweg meer is. Op zo'n moment roept de CEO (vaak snel zonder alle betrokkenen te raadplegen) om een ingrijpende reorganisatie.

In het bedrijfsleven is er een belangrijke les die we kunnen leren van de teleportfunctie in Pac-man: een teleport is verre van een gegarandeerde redding! Het kan je in een zeer gevaarlijke situatie brengen. Het doel van de teleport is niet een onmiddellijke verbetering van het verloop van het spel, het is om te ontsnappen aan een hopeloos vastgelopen situatie, aan een dreigende ramp. Direct na een teleportatie moet je handelen en stappen ondernemen om de controle terug te krijgen. Evenzo zal een ingrijpende reorganisatie in het bedrijfsleven zelden direct een betere situatie brengen. Een reorganisatie is bedoeld om de boel op te schudden en te ontsnappen uit een hopeloos vastgelopen situatie (vaak onzichtbaar voor veel van de medewerkers). Na de relatief gedachteloze sprong die snel moet worden uitgevoerd om een onmiddellijke game over te voorkomen, zal de organisatie een doordachte fase moeten ingaan waarin kleine verbeteringen worden aangebracht om de situatie te optimaliseren.

Als u zich realiseert dat een reorganisatie u niet onmiddellijk winst heeft opgeleverd, probeer dan af te zien van verdere reorganisaties. Zoek in plaats daarvan naar mogelijkheden voor kleine veranderingen en geef het wat tijd.

Als er in boeken minder vaak wordt gesproken over 'verbreken van de stilte', betekent dat dan dat we nu meer stilte hebben omdat het niet langer wordt verbroken?

Chemie als zelfstandig naamwoord heeft in het dagelijks leven twee totaal verschillende betekenissen:

• Een goede sociale relatie:

'Het was zichtbaar dat er chemie was tussen die twee mensen'

• Iets gerelateerd aan een verbinding die zogenaamd slecht is voor mens of milieu. "Chemisch" wordt vaak gebruikt als synoniem voor giftig:

"Er lekte een chemische stof uit de container in zee, waardoor de vissen in gevaar kwamen"

Hoe komt het dat deze twee betekenissen van hetzelfde woord zulke extreem verschillende connotaties hebben? Het wetenschappelijke woord chemie vertegenwoordigt immers elke vorm van reactie tussen twee verbindingen en heeft op zichzelf geen positieve of negatieve betekenis. Water is een chemische stof. Het leven is chemie.

Als chemicus zou ik willen dat ik de negatieve connotatie van moleculaire chemie in het nieuws kon veranderen. Maar als het me echt niet lukt, kan ik misschien de maatschappelijke betekenis van chemie beïnvloeden om dingen consistent te maken:

"Er was chemie tussen die twee! Toen ze elkaar voor het eerst ontmoetten, probeerde ze hem te vergiftigen. Zodra hij hersteld was, explodeerde hij in woede."

Op de een of andere manier heb ik het gevoel dat dit niet zo bevredigend zou zijn.

[afbeelding: Nic McPhee op flickr]

Sommige computerdiensten aan universiteiten worden betaalde diensten. En de primaire reactie in de wetenschapsgroepen is vaak een vechtreactie omdat de realistische kosten van het exploiteren van de bestaande infrastructuur hoog zijn. En als de strijd niet werkt, is er een vlucht naar een gedecentraliseerde infrastructuur. Dit kan goedkoper lijken, maar er wordt zelden rekening gehouden met onderhoud en incidentenbestrijding.

We hebben goede documentatie nodig om mensen te overtuigen van de werkelijke kosten van de alternatieven. Het is zonde als de zeldzame tijd van goede bio-informatica-experts wordt besteed aan inefficiënt serverbeheer.

Photo: CC-BY-SA, Hollingsworth on flickr.com

Met betrekking tot het beheer van onderzoeksdata vertel ik mensen vaak hoe belangrijk het is om een dataset te beschrijven als "wat het is" in plaats van "hoe je het gebruikt".

Een voorbeeld dat mij al een tijd geleden werd gegeven door een biobankexpert in Nederland was de beschrijving van een röntgenfoto van de borstkas: hoogstwaarschijnlijk kan zo'n beeld zowel worden gebruikt om het bot in de wervelkolom te bestuderen als om de toestand van de grote slagaders (bijvoorbeeld de aorta) te bekijken. Als een dergelijke röntgenfoto wordt verkregen, is het waarschijnlijk dat deze slechts voor één doel is gemaakt, maar dat sluit hergebruik op het andere gebied niet uit. Om de herbruikbaarheid van de gegevens te optimaliseren (zie de FAIR-principes), moet een thoraxfoto het label "thoraxfoto" krijgen en niet "röntgenfoto van de wervelkolom", zelfs als deze voor dat specifieke doel is gemaakt.

Ik denk dat dit vergelijkbaar is met een "boekenkast". De meeste "boekenkasten" zijn eigenlijk "planken". Die planken kunnen gebruikt worden om boeken in op te bergen, maar kunnen ook voor andere doeleinden gebruikt worden. Om de vindbaarheid van de juiste opbergoplossing in de winkel te optimaliseren, zou het handig zijn als het label geen specifiek gebruik uitdrukt.

Onlangs hoorde ik nog een heel mooi voorbeeld van hetzelfde principe in een aflevering van de SE-radio-podcast: Functienamen bij het schrijven van computercode. Het verbetert de menselijke leesbaarheid van computersoftware (en dus de onderhoudbaarheid) sterk als elke functie wordt genoemd naar wat het doet, in plaats van naar hoe het wordt gebruikt. Het voorbeeld uit de podcast: noem de functie niet "reformat_email", maar noem hem "remove_double_newlines" als dat is wat hij doet.

Ik heb iemand ooit horen zeggen "Onderzoekers zijn heel slecht in staat de mogelijkheden voor hergebruik van hun eigen data te beoordelen". Het is waar: een onderzoeker die de aorta bestudeert, zal op zijn eigen röntgenfoto's niet eens de ruggengraat zien, laat staan nadenken over manieren waarop de gegevens kunnen worden hergebruikt door botonderzoekers. Ik denk dat het labelen van een dataset met hoe deze wordt gebruikt hier een gevolg van is. Een getrainde bibliothecaris/archivaris, met training in classificatiesystemen, zal zo'n fout snel doorzien en een betere naamgeving voorstellen.

Heb je je ooit afgevraagd hoe je de vijf sterren in je fotocatalogus kunt gebruiken? Ik heb mensen horen zeggen: er zijn maar twee soorten foto's: foto's die je aan iemand zou kunnen laten zien, en foto's die je aan niemand zou laten zien. Is kiezen tussen nul en één ster niet genoeg?

Via twitter zag ik een heel cynische opmerking over het stellen van vragen na een wetenschappelijke lezing met een stroomschema dat de meeste mensen ontmoedigt om ook maar iets te vragen. Dit komt totaal niet overeen met mijn ervaring met het organiseren van symposia en congressen. Meestal zijn vragen zeer welkom en zijn mensen veel te verlegen om hun visies te delen. Ik heb daarom een weerlegging gemaakt in de vorm van het volgende stroomschema dat volgens mij een betere weergave is van de te volgen gedachtegang.

Verhaal 1. De European Open Science Cloud had zijn lanceringsbijeenkomst in Wenen op 23 november 2018. Lezingen vertegenwoordigden grote (honderden miljoenen euro's) Europese wetenschappelijke projecten gericht op één onderwerp, en vertelden het publiek hoe belangrijk de EOSC zal zijn.

Verhaal 2. Ik beantwoord graag vragen op Quora. Laatst vroeg iemand of het ongezond is om in een vochtig klimaat te leven. Het kostte me 2 uur om gegevens over klimaatvochtigheid en verwachte levensduur te vinden, beide per land samen te vatten en te correleren. Ik kon voor slechts 46 landen beide nummers vinden.

Mijn conclusie? Een goed functionerende European Open Science Cloud zal vooral zeer nuttig zijn om de antwoorden op kleine vragen te versnellen door het mogelijk te maken verschillende datasets uit verschillende bronnen te koppelen. De grote projecten die hun eigen petabytes aan data verzamelen, zullen precies hetzelfde kunnen doen, met of zonder een science cloud. Maar de meeste wetenschap bestaat uit veel kleinere vragen, waarbij mogelijk gegevens worden samengevoegd tot oplossingen voor grote maatschappelijke doelen. Dit soort projecten zijn het meest gebaat bij datasets die voldoen aan standaarden. Zij zullen profiteren van de EOSC. En daarom is het jammer dat de stem van dergelijke projecten niet vertegenwoordigd was tijdens het lanceringsevenement.