^{De ongevraagd advies van deze week gaat over de herprogrammeer de overheid petitie. Je vindt alle Ongevraagde Adviezen via deze Spotify playlist, deze editie vind je op BNR en op Spotify.}

Er is deze week een “burgerinitiatief” uitgekomen met IT-tips voor de overheid, spekkie naar jouw bekkie zou je denken, maar helaas… Er wordt dan wel een belangrijk onderwerp aangekaart, maar het is het toch net niet.

Laten we eerst even kijken wat er wel aardig is, bijv punt 3 (Maak de publieke zaak aantrekkelijker voor technisch talent) ook ik heb al eerder (ook in mijn BNR columns) gepleit voor een betere beloning van IT-personeel bij de overheid. Het is tamelijk maf dat overheden wel partijen als Pink Roccade mogen inhuren, maar een ervaren senior developer zonder blikken of blozen 70k/jaar aanbieden! Diezelfde developer kan prima bij Pink Roccade gaan werken voor het dubbele en dan uitgehuurd worden aan de overheid, dat is natuurlijk niet goed.

Punt 5 (Verbind uitvoerders en beleidsmakers met elkaar) vind ik ook ijzersterk, want het is inderdaad gek dat IT-ers, die beleid moeten gaan uitvoeren aan de technische kant, niet meteen mee mogen denken, dat is vragen om technisch onuitvoerbaar beleid.

Dus, jouw naam staat er ook onder…?

Nee, dat ook weer niet, want er is ook een hoop op het voorstel aan te merken! Het is echt een gemiste kans dat geen van de initiatiefnemers echt ervaring heeft met “legacy software” (software die al heel lang meegaat) Eigenlijk is maar 1 van de initiatiefnemers een techneut, de andere zijn media-persoonlijkheden en andersoorting “tech adjacent”, zoals een designer en een recruiter.

Nu is dat natuurlijk in de basis niet erg, je kan ook als amateur veel weten door te lezen en/of je goed laten informeren, maar de gaten in dit voorstel laten goed zien dat dat niet gebeurd is. 

De overige drie punten tonen een naïef beeld van wat software maken is. Zo vraagt het manifest om kleine autonome teams die nieuwe projecten kunnen oppikken (itt de nu vaak erg logge bureaucratische teams) en noemt daarbij als voorbeeld van hoe goed dat kan werken de welbekende CoronaMelder app. Maar natuurlijk was een geheel nieuwe app bouwen een simpel en overzichtelijk project, iedereen die wel een zelf een app gemaakt heeft, of een ander stuk nieuwe software weet dat in programmeren de wijsheid “alle begin is moeilijk” nou juist niet geldt! Alle begin is makkelijk, want als je iets nieuws maakt, hoef je geen rekening te houden met verouderde codes, mensen die nog op Windows 95 werken, of een veranderende wereld. Dus een nieuwe app zet je relatief eenvoudig in elkaar (we noemen dat ook wel een “greenfield” project) Om dat aan te halen als voorbeeld van wat mogelijk is, is erg kortzichtig!

Dat is als zeggen dat een IKEA schuurtje in elkaar zetten in een weekend kan, en je dan afvragen waarom het drie weken duurt om een rieten dak te vervangen. Wie dat zegt, snapt niet hoe software onderhouden wordt (of wil het niet snappen). 

Interessant in dit kader is ook dat ze een zeer niche term in het stuk gebruiken, namelijk “technische schuld”. 

Wat is dat, technische schuld? 

Ik denk dat het goed is om dat nog even toe te lichten ja!

Technische schuld (in het Engles: technical debt) is het idee dat je soms als je code schrijft, een soort lening afsluit. Als je even snel iets in elkaar zet, en het niet netjes opruimt, dan kan je daar later last van krijgen. Die schuld moet je dan zien als, in de basis, iets positiefs zoals een bedrijfslening of een hypotheek. Je investeert om er wat voor terug te zien, bijv om snel je app te kunnen lanceren.

Dat niet netjes opruimen moet misschien ook nog wat meer toegelicht worden, want hoe kan code nu “rommelig” zijn, denk je nu misschien? Code is toch altijd heel gestructureerd, anders werkt het toch niet? Dat klopt, maar toch zijn er dingen die je rommelig kan noemen, bijv. als je in plaats van dingen netjes bij elkaar, die juist door elkaar zet. Voor een computer maakt dat niet uit, maar voor een toekomstige lezer is dat verwarrend. Dat maakt het moeilijker om te snappen wat de code doet, en pas je die aan, dan maak je sneller foutjes.

Net als een gewone schuld, moet je ook technische schuld wel “terugbetalen”, dat betekent periodiek je codes opruimen. En daar knelt, niet alleen bij de overheid trouwens, de schoen! Want klanten en gebruikers willen altijd nieuwe dingen, of minder bugs! Maar die willen jou niet betalen als je een maand niks levert en alleen aan het opruimen bent. Dat heeft ook met onze eigen communicatie te maken hoor. Als jij in het ziekenhuis bent en de dokter wast eerst haar handen voordat ze je diepe snee hecht, dan zeg jij niet: “he kom eens snel helpen, wat jij nu doet, daar betaal ik niet voor!” Je weet dat handen wassen nu eenmaal een heel relevant onderdeel is van medische zorg. Mensen weten helaas niet dan technische schuld afbetalen ook bij het werk hoort. Echter is het ook zo dat programmeurs zelf opruimen vaak niet zo leuk vinden (het zijn net mensen) en dat het daardoor ook minder vaak gebeurt.

Nu we technische schuld hebben toegelicht moeten we nog een tandje dieper gaan, bear with me, want lang niet altijd is technische schuld, de schuld (haha) van de programmeur. Hier zijn een aantal voorbeelden:

• Nieuwe versie Als bijv. een leverancier van software een nieuwe versie maakt, dan moet jij als programmeur opeens ook aan het werk om jouw software aan die nieuwe versie aan te passen. Zelfs als je code opgeruimd is, kan dat veel tijd kosten.
• Nieuw idee Soms verzint een klant opeens een nieuwe eis. Als je in je software “groenten en fruit” niet als losse categorie hebt staan, en de overheid wil dat anders belasten, dan moet jij de boel ombouwen. Is een blik tomaten bijvoorbeeld groenten? Je moet dan data aanpassen en een stuk code bouwen omm automatisch te bepalen of iets groente is, voordat je aan de slag kan met de echte aanpassing, ook in een nette code base.
• Onvoorzien probleem Soms kan je niet overzien wat er mis kan gaan met software. De milleniumbug is een goed voorbeeld, de mensen die in de jaren 50 en 60 software maakten, konden nog niet bedenken dat zoiets 30 of 40 jaar in gebruik zou blijven. Dat was gewoon niet te voorzien, want software was in het begin altijd zeer kortlevend.
  In mijn eigen software Hedy hadden we ook zoiets. Een component dat we gebruikten (Ace genaamd) werkt niet goed met Arabische tekst. Maar… in het begin hadden we alleen Engels en Nederlands, dus werkte alles goed, pas toen we ook Arabisch gingen ondersteunen, ontstond het probleem. En toen zijn we maanden en maanden bezig geweest met ombouwen!

Aan deze voorbeelden zie je dat “technische schuld naar 0” geen betekenisvolle uitspraak is. Je kan de toekomst niet voorspellen, en je kan dus ook je huidige technische schuld helemaal niet in een getal vangen. Hoe ga je bepalen of het al 0 is, hoe ga je dat borgen? Alleen een amateur zou zo’n uitspraak doen.

Het is echt als vragen om wereldvrede. Goed idee, iedereen mee eens. En wat gaan we nu precies doen om dat te bewerkstelligen…?

Missen er belangrijke zaken?

Wat ook een enorme gemiste kans is, is het ontbreken van enige referentie aan open source. Niet alleen was de CoronaMelder app vlot klaar, ook konden burgers het proces volgen en de code lezen. Dat lijkt me nu precies het soort transparantie dat deze bezorgde burgers na zouden streven, dat niet noemen (nadat het wel op het toenmalige Twitter vaak langskwam, omdat wij een minister hadden met een GitHub account) is op z’n minst opvallend te noemen! Hoe kun je dat nu niet aanstippen? Een bezorgde burger zou een burger moeten zijn die niet alleen wil adviseren maar zichzelf (en anderen) ook wil informeren!

Wat zou die agenda dan kunnen zijn volgens jou?

De website meldt dat het initiatief gestart is door “bezorgde burgers” maar dat is natuurlijk niet echt juist, deze burgers hebben duidelijke raakvlakken met tech en met deze petitie. Meest krom is dat de hoofd-initiatief nemer, Onno Eric Bloem, een direct belang bij meer en beter betaalde banen bij de overheid, omdat hij eigenaar is van een recruitmentbureau!

Ik word er echt een beetje verdrietig van als ik zie dat NRC deze figuur “tech ondernemer” noemt, dat lijkt me wel een zeer ruime interpretatie van tech, voor iemand met geen (althans geen voor mij vindbare) ervaring met wat voor software maken dan ook! Met zo’n beschrijving klinken adviezen toch echt anders voor een leek, dan als iemand tech recruiter wordt genoemd en zijn gebrek aan technische kennis wordt benoemd en bevraagd.

En het gebrek aan diepte is echt niet alleen iemand’s titel en ervaring, het stuk in de NRC is in feite gewoon het overtikken van de petitie zonder kritische vragen over bijv technische schuld, open source etc. Het laat eens te meer zien dat ook journalisten van tech weinig kaas gegeten hebben en niet goed begrijpen waar dit stuk, en dus ook de IT-crisis bij de overheid precies over gaan.

En dan nu het advies aan de overheid

Hoe kritisch ik ook ben, laat je door dit laffe stukkie niet gek maken, technische schuld is complex, de overheid is aan veel verandering onderhevig dus denk zelf goed na over hoe je je software managet, maar wel graag open source en met betere salarissen!