De WBSO (Wet bevordering speur- en ontwikkelingswerk)-subsidie voor ict staat onder druk. Het nationale WBSO-budget is al jaren ongeveer gelijk met circa 1,2 miljard euro. Toch neemt de aangevraagde hoeveelheid jaarlijks toe, waarbij ict- en programmatuurontwikkeling een steeds groter aandeel vormt. Elk jaar legt men restricties op om het aantal aanvragen in te perken. De Rijksdienst voor Ondernemend Nederland (RVO) lijkt dit jaar extra streng, met meer afwijzingen als gevolg
WBSO-subsidie is bedoeld om werkgevers te stimuleren research en development te doen. Voorheen was voor veel ontwikkeling WBSO aan te vragen. Er is echter een strengere wind gaan waaien waardoor veel aanvragers bot vangen. Zo konden bijvoorbeeld directeurs met een eigen holding die niet mee programmeerden, maar wel intiem betrokken waren bij het ontwikkeltraject, voorheen subsidie krijgen. Daarnaast was het voorheen geen eis dat je programmeerde, de Nederlandse Spoorwegen won hierover nog een belangrijke rechtszaak in 2015.
Echter, naar aanleiding van die verloren rechtszaak, heeft het ministerie van Economische Zaken de WBSO-wetgeving aangepast, waardoor nu een eis is dat programmatuur in een ‘formele programmeertaal’ wordt vastgelegd. Dan rijst gelijk de vraag: wat is een formele programmeertaal? Hier is geen officiële definitie voor, en deze wordt ook nergens gegeven. Het lijkt erop dat hoe abstracter een taal is, hoe minder het in aanmerking komt als programmeertaal. Maar is dat wel van deze tijd?
Tijdmachine
Ik neem je graag de tijdmachine in voor een lesje historie.
In het begin van het computertijdperk programmeerden we in binaire code (iets wat in de zeventiende eeuw al bedacht was), nullen en ééntjes, ook bekend als machinetaal. Dit is in principe onleesbaar voor mensen. Daarna, in de jaren vijftig, bedachten we de assembleertaal (of assembly) bedacht, een meer leesbaarder variant van machinetaal, maar nog steeds bewerkelijk.
Daarna (eind jaren 50) volgden de modernere talen als Fortran, C, C++ en later nog talen als C#, Java en nu zitten we in het tijdperk van Javascript, PHP, Python en bijvoorbeeld Swift. Al deze talen komen nog steeds voorbij in meerdere of mindere mate. Vaak is de afweging controle en efficiëntie (oudere talen als C of C++) of productiviteit (moderne talen als Javascript en Python) of andere specialistische toepassingen.
Een belangrijke trend is dat bij elke moderniseringsslag steeds meer door de taal opgepakt wordt, en steeds minder door de programmeur, waardoor zij in kortere tijd en met meer standaardlibraries veel functionaliteit creëren.
Glijdende schaal
Hier ergens legt RVO de grens op deze glijdende schaal. In talen als C++ en Java is er geen discussie, maar in een moderne abstractere taal als Swift komen vaak bezwaren naar voren. Het zou onmogelijk zijn om technisch nieuwe software te realiseren, omdat deze talen al veel functionaliteit bevatten. Is het een vereiste dat je met ‘oudere’ programmeertalen werkt? En past dit wel bij de term ‘innovatie’, die juist bedoeld is voor het opzoeken en oprekken van de huidige stand der techniek en het realiseren van vernieuwing?
Nog nieuwer is het model driven development, waarbij softwareontwikkelaar met behulp van een grafische interface softwareapplicaties kunnen bouwen. Hiermee is dus code te genereren zonder te kunnen coderen. Dit ziet RVO al helemaal niet meer als formele programmeertalen, terwijl hiermee juist het snelst nieuwe software is te generen.
Het wiel opnieuw uitvinden
Er ontstaat een paradoxale situatie waarin verouderde technologie vereist is om in aanmerking te komen van innovatiesubsidies. Het wiel opnieuw uitvinden, krijgt opeens een nieuwe betekenis, waarbij de analogie is dat de nieuwste rubbers en kunststoffen veel te goed werken, waardoor het voor de innovatie noodzakelijk is met ongeschikte oudere materialen en gereedschappen te werken. Hoewel dit in technische zin begrijpelijkerwijs tot een hoop kopzorgen leidt, kan dit toch redelijkerwijs niet het criterium zijn van innovatie en zeker niet de bedoeling zijn.
In de wens van RVO om het budget binnen de perken te houden, lijkt nu een gekke afslag gemaakt te zijn, waardoor een arbitraire en ondoorzichtige scheidingslijn gemaakt is tussen programmeertalen die wel tot innovatie kunnen leiden en talen waarin dat niet zou kunnen. Door de huidige strikte scheidingslijn vallen veel innovaties buiten de boot en wordt vooruitgang in de weg gezeten. Een kwalijke ontwikkeling.
Nils,
Gaat het er niet vooral om wat je met die programeertalen doet ?
Ik heb eens een project gedaan waarbij ik OOP in C (dus niet C++) heb gebruikt.
Leuk om te doen, maar wat ik uiteindelijk heb gedaan was niet heel erg bijzonder te noemen anders dan dat ik eens een keer niet kant en klare rommel bij elkaar zat te klikken.
Ik deel heel erg je insteek en ook ik zie al die scrummende scholieren die afhaken zodra ze eens wat bitjes moeten manipuleren ook niet zo zitten.
Maar het gaat er in eerste instantie om dat je inovatief bezig bent, en binnen de WBSO kom ik dat nu niet zo bijster veel tegen.
Meestal gaat het gewoon om de zoveelste EP of het zoveelste prul programmaatje voor marketeers.
Inovativiteit op meer complexe systemen ben ik nog niet tegen gekomen (wellicht kijk ik niet goed)
Wat mij ook verbaast is dat er slechts een inspannings verplichting is zonder een resultaat verplichting.
Ik verzin iets om een karretje door mijn magazijn te laten rijden.
Oops lukt me toch niet helemaal, te hoog gegrepen.
Inspanning geleverd, geen resultaat.. prachtig.
Zo bezien was dat datacenterbehang op die mbo scholen misschien wel innovatief.
Dat is toch niet gek dat de spreadsheet helden RVO van bovenaf de opdracht krijgen om minder subsidie uit te keren omdat een hoge ambtenaar (of zelfs minister) zijn huishoudboekje op orde wil brengen?
Die hebben dan waarschijnlijk een paar experts bevraagd over hoe ze dit kunnen doen en vanuit de verschillende mogelijkheden degene gepakt die het makkelijkst te hanteren valt.
Tevens durf ik wel te stellen dat als zij de broncode van een WBSO project onder ogen zouden krijgen niet eens zouden weten naar welke taal zij zitten te kijken.
Overigens is m.i. voor heel veel IT bedrijven de WBSO ook niet gek veel anders dan een extra zak met geld waar je weinig voor hoeft te doen dan een administratie op orde te maken. Dat de teugels strenger worden aangetrokken is dan ook niet meer dan terecht. Maar dan wel met zinnige criteria.
Innovatie wordt niet gedreven door programmeertalen, dit zijn slechts “enablers”
Innovatie komt uit (creatieve) breinen van mensen
@Pascal:
Het gaat inderdaad om wat je er mee doet, maar er is tegelijkertijd dus een harde selectie van talen die wel in aanmerking komen en talen welke niet, wat natuurlijk weinig te maken heeft met een innovatiegehalte an sich. Neemt niet weg dat veel ‘programmatuur’ het koppelen van systemen is en dat programmeren niet altijd innovatief is.
@Johan: Eens, kritisch kijken naar de regeling en je definitie van innovatie mag en is in mijn bescheiden mening ook de taak omdat het uiteindelijk om belastingcentjes gaat. Neemt niet weg dat zoals je ook zegt de criteria wel zinnig moeten zijn.
@PA VA KE; Helemaal eens, maar volgens de letter van de wet dus helaas niet.