- Gegevens
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
In onze zandloper van life science tools wordt voortdurend nieuw zand toegevoegd. En het meeste loopt na een tijdje over de beker. Sommige tools leveren nooit wat de auteur dacht dat ze zouden doen. Sommige zijn gemaakt om een enkel probleem op te lossen en worden terecht losgelaten als dat klaar is. Maar veel tools worden gepubliceerd en als wees achtergelaten. Alleen een selectie van tools die lijken nuttig te kunnen zijn voor een groter publiek, haalt de hals.
In de praktijk is de hals te smal. Er zijn veel meer waardevolle hulpmiddelen dan er kunnen worden aangepakt. Een team als het onze kan helpen om de hals groter te maken door bestaande onderzoekstools breder inzetbaar te maken ten dienste van levenswetenschappers met een duidelijke behoefte (wij noemen dat professionalisering). Maar het is soms moeilijk om financierende partijen te overtuigen om hiervoor te betalen. Het is ook moeilijk om onderzoekers te overtuigen om te werken aan het verbeteren van hun software: professionalisering levert geen nieuwe high-impact papers op. We werken eraan om de financiers ervan te overtuigen dat het beter is bestaande successen te professionaliseren dan ze opnieuw uit te vinden met nieuw onderzoeksgeld. En we werken eraan om de wetenschappers ervan te overtuigen dat professionalisering van hun output zal leiden tot hogere citatiescores op hun bestaande publicaties.
De wetenschap wil nieuwigheid. En het huidige Nederlandse financiële klimaat is gericht op toegepaste wetenschap, op innovatie in de samenleving. Kijk naar het diagram en je ziet dat deze moeilijk te combineren zijn. Innovatie begint waar nieuwigheid eindigt. De enige manier om de combinatie te maken, is door ontwikkeling mee te nemen.
Foto door graymalkn op flickr
- Gegevens
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.
- Gegevens
Stel je een mechanische werkplaats voor. Je komt met een probleem dat zij oplossen. Wat verwacht je? Je verwacht met hen samen te werken, grofweg in de volgende vijf stappen:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Ontwerp. Ze gaan een tekening maken
- Onderdelen. Zij (mogelijk meerdere mensen parallel) zullen het ontwerp gebruiken om onderdelen te selecteren en te vervaardigen
- Product. Ze zullen de stukken aan elkaar lassen tot het ding dat je nodig hebt
- Test. Je test het en het kan kleine aanpassingen vereisen
Stel je nu een softwareworkshop voor. Je komt met een probleem dat zij oplossen. Wat verwacht je?
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Product. Zij zullen de softwaretool maken
- Test. Je alfatest, ze repareren, je bètatest, ze repareren. Herhaal tot bevredigend
Hoe komt het dat deze lijst slechts drie in plaats van vijf stappen bevat? En waarom veroorzaakt de laatste stap altijd zoveel pijn? Zou dit verschil de oorzaak kunnen zijn waarom zoveel softwareproducten falen? Wat is het echte verschil tussen software- en hardwareontwikkeling?
In plaats van te proberen het softwareprobleem in één keer op te lossen, stelt u zich eerst een hardwarewerkplaats voor die als volgt werkt:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Product. Ze zullen materialen aan elkaar lassen tot een stuk gereedschap
- Test. Je test, zij repareren, je test opnieuw, zij repareren. Herhaal tot bevredigend
Hoe waarschijnlijk is het dat deze procedure sneller is dan de procedure in vijf stappen? Hoe duidelijk is het welke stukken aan elkaar moeten worden gelast? Kunnen hierdoor meerdere mensen samenwerken aan het product? En hoeveel werk is het testen voor jou? Hoeveel afval komt er vrij in het proces? Je zou dit soort beunhazerij niet accepteren! En mijn punt: je moet het ook niet accepteren van een softwarewerkplaats.
Een goede softwarewerkplaats zou dezelfde vijf stappen gebruiken als de goede mechanische werkplaats:
- Specificeer. Je beschrijft het probleem in de vorm van een functionele specificatie
- Ontwerp. Zij maken een (modulair) ontwerp
- Stukken. Zij (eventueel meerdere programmeurs parallel) zullen het ontwerp gebruiken om softwaremodules te bouwen en te selecteren
- Product. Zij zullen de modules gebruiken om de software te bouwen die je nodig hebt
- Test. Je test het en er zijn misschien kleine aanpassingen nodig
Investeren in een ontwerp zal resulteren in een oplossing die het gestelde probleem echt oplost en geen eindeloze iteraties vereist om het goed te krijgen. Het lijkt misschien een trage oplossing, maar dat is bedrog: je krijgt daadwerkelijk een resultaat dat je brengt waar je wilt zijn, ook als je in de toekomst nieuwe aanvullende wensen hebt.
(Ik wil graag een oud-collega bij Bruker AXS bedanken die me deze mooie vergelijking heeft gegeven. Ik weet dat hij anoniem wil blijven op het internet. Beeldcredits: Dystopos op Flickr)
- Gegevens
Als je geen gebruikersfeedback krijgt voor je software, zijn er twee mogelijke redenen.
- Het is slecht. Niemand gebruikt het.
- 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?
- Gegevens
Veel goede software in de academische wereld wordt ontwikkeld door promovendi of postdocs. Beide groepen hebben tijdelijke contracten en heel vaak sterft de software aan het einde van het contract.
Je kunt academische software vergelijken met een Formule 1-raceauto: het is erg snel, mooi, technologisch geavanceerd. Maar erg moeilijk te besturen en heeft regelmatig onderhoud nodig. De enige manier om hem op de weg te houden, is door de bestuurder en de ontwerper nauw samen te laten werken.
Om de technologie die is ontwikkeld voor de Formule 1-raceauto in de praktijk te kunnen gebruiken, moet de auto opnieuw worden ontworpen:
- Iedereen met een normaal rijbewijs moet ermee kunnen rijden.
- Het moet mogelijk zijn om op verschillende soorten wegen te rijden, niet alleen op een gepolijst racecircuit.
- Het moet mogelijk zijn voor een regelmatig opgeleide servicemonteur om het te onderhouden.
- Het onderhoudsinterval moet verhoogd worden van 200 km naar 25000 km.
Het is duidelijk dat bij het ontwerpen van auto's deze veranderingen niet de verantwoordelijkheid zijn van de ontwerpers in het Formule 1-team. Er zijn andere ontwerpers die gespecialiseerd zijn in normale auto's.
De equivalente concepten in softwareontwerp zijn:
- Het programma moet gebruiksvriendelijk worden gemaakt. Het moet bruikbaar zijn voor incidentele gebruikers die niet ook computerhackers zijn.
- Het moet robuust genoeg zijn om te werken met echte gegevens zoals echte gebruikers die tegenkomen.
- Het gebruik en de installatie moeten goed worden gedocumenteerd.
- Het moet voor veel datasets zonder toezicht kunnen werken en niet na een beperkte tijd kapot gaan, b.v. via een ogenschijnlijk niet-gerelateerde upgrade van het besturingssysteem of een kleine wijziging in een onderliggende webservice.
Grappig genoeg wordt bij veel grotere projecten verwacht dat de ontwerpers van de Formule 1-software dit redesign ook gaan doen. Dit is een sterk contrast met auto-ontwerp! In NBIC-II zullen we deze fout niet maken. Software de extra stap vooruit helpen wordt één van de belangrijke taken van ons Central Engineering Team. En dit team zal specialisten bevatten op het gebied van industriële software-engineering.
We gaan van de Ferrari's Volkswagens maken. En we zullen er trots op zijn!