Nederlandse overheid zet broncode van stopgezet Plooi-platform op GitHub

Het Nederlandse ministerie van Binnenlandse Zaken heeft de broncode van de opgedoekte app Plooi online gezet. Dat platform werd onlangs stopgezet omdat het achterhaald was, nadat de overheid er 28 miljoen voor had betaald. Nu staat de code na een Woo-verzoek online.

Het ministerie van Binnenlandse Zaken en Koninkrijksrelaties heeft de broncode van het platform op GitHub gezet. Dat is te gebruiken onder een EUPL-licentie, waarmee de code ook kan worden hergebruikt door burgers. Het enige dat ontbreekt in de code zijn 'werkbestanden van het ontwikkelproces', lettertypes en logo's. Die zijn in dit geval auteursrechtelijk beschermd. Ook is bepaalde code weggelaten die mogelijk voor veiligheidsrisico's kunnen zorgen zoals informatie over de gebruikte infrastructuur. Er is ook broncode weggelaten waarmee ontwikkelaars konden worden achterhaald.

De broncode is openbaar verschenen naar aanleiding van een verzoek op basis van de Wet Open Overheid. Een burger had gevraagd om de broncode. Het ministerie concludeert dat er geen reden is die niet te geven en heeft die daarom direct op GitHub gezet. Dat is in lijn met een recente ontwikkeling binnen de Nederlandse Rijksoverheid. Die wil meer applicaties en software openbaar ontwikkelen of beschikbaar maken. In 2020 zei het kabinet al dat het de werkmethode rondom de corona-app vaker wilde gebruiken. Die app werd in samenwerking met experts gemaakt en grotendeels openbaar ontwikkeld en gepubliceerd. Dat bevestigde later ook staatssecretaris Alexandra van Huffelen van Digitalisering in een interview aan Tweakers.

Plooi was een overheidsproject dat vorig jaar werd stopgezet. De overheid wilde met Plooi, het Platform Open Overheids Informatie, een app bouwen waar overheden zelfstandig gegevens openbaar konden maken. Na een aanbeveling van het Adviescollege ICT-toetsing besloot minister Hanke Bruins Slot het platform te stoppen. Door de eisen van de nieuwe Wet open overheid zou het platform zo erg onder handen moeten worden genomen, dat het niet realistisch was het verder door te ontwikkelen. De nieuwe wet bracht eisen met zich mee rondom bijvoorbeeld de zoekfunctie, die daardoor compleet opnieuw moest worden opgebouwd. Toen de minister de stekker uit het project trok, had de Nederlandse overheid al 28 miljoen euro voor het platform betaald.

Door Tijs Hofmans

Nieuwscoördinator

09-06-2023 • 18:25

105

Reacties (105)

105
102
39
2
0
52
Wijzig sortering
Voor wie echt geinteresseerd is in hoe zo'n bedrag kan ontstaan en waar het falen van ICT projecten door ontstaat, kijk even naar wat het adviescollege ICT schrijft, en het CIO advies omtrent PLOOI van eerder. Daar staan eigenlijk de belangrijkste factoren genoemd, en die hebben meestal te maken met geen strakke sturing van projecten, en niet goed reageren op grote wijzigingen in de verwachtingen van een systeem (in dit geval wijzigingen in de WOO) en zorgen dat wat je bouwt eigenlijk iets is waarvan je goed onderzoek hebt gedaan dat er vraag naar is.

https://open.overheid.nl/...42dbfadb7741973b91c5c/pdf
https://open.overheid.nl/...19e6db84022aa619c972b/pdf

[Reactie gewijzigd door keesface op 22 juli 2024 15:22]

Ik heb door de GitHub code gekeken en ik vraag me echt af waar die 28 miljoen heen is gegaan. Zowel de kwaliteit als de hoeveelheid code laten voor mij niet echt die waarde zien. Natuurlijk komt er veel meer kijken bij software ontwikkeling dan puur de code schrijven, maar dit eindresultaat is toch wel best triest te noemen vergeleken met de investering.
Zoals je zelf al aangeeft is het niet alleen de app waar geld naartoe gaat, maar ook de onderliggende infrastructuur. De servers, huur van ruimte in datacenters, de verbindingen met diverse interne en externe partijen.

Maar ook zaken als licenties, support contracten etc.

Om het over zaken als personeelskosten, projectmanagement, juridische zaken etc nog maar niet te hebben. En zaken als training en opleidingen van de gebruikers.

Als zo'n project jaren loopt kunnen die kosten aardig aantikken.
Dat klopt natuurlijk, maar worden die kosten die je noemt ook allemaal al in de ontwikkelingsfase gemaakt, waar dit project niet uit is gekomen?
Dat vraag ik me serieus af.
Ben wel benieuwd naar de details. Als 1 of andere minister vond dat het in een "eigen" datacenter moet draaien dan moet je, afhankelijk vd schaal, vooraf een investering doen op het vlak van hardware
Dat is natuurlijk speculatie, net zoals je kunt speculeren of dat wel een nieuw datacenter moet zijn geworden, of dat een van de bestaande datacenters van de overheid (her) gebruikt zouden kunnen worden.
Nja precies. Ben wel benieuwd eigenlijk. Al is een nieuw datacenter wel wat overdreven. Bij ons bijv. Krijgt een project 4 of 5 nodes "gratis" en alles daarboven (of hogere specs per node) levert een gesprek / rekening op.

Ps. Gratis in de zin van de kosten zitten verwerkt het uurloon vd engineers

[Reactie gewijzigd door Mellow Jack op 22 juli 2024 15:22]

ik kan je alvast zeggen dat, in de ontwerpfase op zijn minst gekeken moet zijn naar...

infra beheer, wie gaat wat doen, hoeveel kost dat, welke veiligheidsnormen gelden er etc..
voor zo'n inventarisatie moet je gewoon een fatsoenlijke it-specialist inhuren en dat zal lang niet altijd helemaal goed gaan, de beste prijs-kwaliteitsverhouding hebben...

vervolgens moet zo iets in een proefopstelling draaien en moeten er zowel technische als juridische toetsing plaatsvinden en vooral dat laatste is nogal heftig want AVG wetgeving etc heeft een behoorlijke impact gehad op eigenlijk alle ict in de EU. (zelfs als heel veel bedrijven daarin nu nog steeds gruwelijk achterlopen).

dit zijn toch al 2 voornamelijk niet-technische niet-productieve (in de zin van code toevoegen) processen waar je gemakkelijk miljoenen aan uit kunt geven voordat je die zaken echt op orde hebt.
en dat fabeltje dat dat alleen bij overheden zo werkt kan ik ook wel uit de lucht trekken dat is echt dikke onzin bij grotere bedrijven gaat het precies net zo... daaar hoor je er alleen niets van omdat dat in principe niemand wat aan gaat.
In bedrijven moet je echt wel wat beter als proef opzetten alvorens de bazen duizenden laat staan miljoenen uitgeven.

En als ze miljoenen uitgeven en het project mislukt gaat het bedrijf failliet en als ze geluk hebben dit te kunnen overleven gaan de koppen rollen. Geen van beide is hier gebeurd, de regering heeft niemand aansprakelijk gesteld want de burger betaalt toch, het bedrijf die de code schrijft is niet failliet, zij krijgen nog meer contractjes afgesloten met de overheid. De overheid is niet afgestapt.

Adhv de LOC zou dit project enkele duizenden euro’s gekost hebben aan programmeurs. We spreken over meer dan 20M euro, dan had je wel een kloon van Solr of ElasticSearch verwacht.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 15:22]

Adhv de LOC zou dit project enkele duizenden euro’s gekost hebben aan programmeurs
Voor 10k heb je 2 ontwikkelaars en een tester voor een week als je het een externe partij laat doen. Intern misschien 3 ontwikkelaars en 2 testers... Voor een week. Knap als je dat allemaal in een week kan doen.

Je onderschat serieus de kosten van je personeel bij het ontwikkelen van software. En dan hebben we het puur over de techneuten. Want je hebt ook een analist nodig, PO, designer, architect, security enz. Niet alle rollen heb je fulltime nodig, maar die trekken ook mee in de totale kosten.

Meedoen aan een bid voor de overheid kost je al tientallen duizenden euros, afhankelijk van de grote van het project.
Heb je de code gezien? Het staat op GitHub. Het is letterlijk een paar honderd lijntjes code en een groot deel van de code is al automatisch gegenereerd van de tooling/IDE uit.

Ja, ik ben inderdaad deels softwareontwikkelaar. Ik weet wat ik kost, de code die je ziet is het start van een project, een paar configuraties voor oa Solr en een backend, nginx, een paar Docker configuraties een beetje concept code voor de backend, een paar libraries en code gekopieerd van elders, het is heus geen project dat al 20M Euro aan uitgegeven is, moest ik deze code aanleveren zelfs na 2M uit te geven mag ik naar de gevangenis voor verduistering.
ik weet niet hoe jij telt, maar als ik alleen de lijnen code van de java bestanden bij elkaar optel kom ik uit op 34.333 lijnen code. De tests in AanleverenControllerTest.java heeft al 1337 lijnen code. Ik doe de telling niet "netjes" want ik kijk puur naar het aantal lijnen (ook lege regels) in een bestand en ik kijk ook niet of het wel of niet gegenereerd is, maar een paar honderd regels code is zwaar, zwaar overdreven.

Ik heb zelf een project wat rond de 50k regels code heeft. Die 50k regels zijn in de loop der jaren zoveel veranderd dat het niet echt terecht is om puur uit te gaan van het aantal lijnen code. Hoe vaak is dat in dit project voorgekomen dat code opnieuw geschreven moest worden door wijzigingen in de wensen/wet.

Dit doe je ook niet in je eentje, hier zit een heel team achter van ik schat iets van 15 tot 25 mensen, van designers, testers, analisten en ontwikkelaars tot aan project en service management, architectuur, security enz. Dit is geen project die iemand in zijn zolder even in elkaar zet.

Pas als je in grote aanbestedingstrajecten meewerkt en ziet wat er allemaal bij komt kijken (bijvoorbeeld dat iedereen een VOG moet aanvragen om maar iets flauws te noemen) dan besef je pas hoeveel geld hier mee gemoeid is. Bovendien zijn deze kosten ook nodig voor het beheer en onderhoud van de OTA infra. Dat gaat al snel richting de (tien?)duizenden euros per maand afhankelijk van de wensen zoals een failover locatie enz.
Meer dan de helft van de LOC die je telt zijn open source libraries die gewoon overgenomen worden als je binnen een React of NodeJS project werkt (npm install).

En lege lijnen zijn geen LOC, dat is al sinds de tijd van OS/2 niet meer gedaan bij elke serieuze ontwikkelaar (lees maar in over de geschiedenis van LOC bij IBM) en een groot deel van de Java imports en tests zijn gewoon auto-gegenereerd, rechts klik, maak test, zelfde met de Docker en andere lijnen, boilerplate, overgenomen van een open source project/stackoverflow of auto gegenereerd. Een groot deel (~50 lijntjes) van de JavaScript is het herimplementeren van oa JavaScript functies (zoals function keys() { return arr.items } dat volgens jouw elke functie zoals deze als 5 LOC telt.

Zelfs al tel je 20,000 “echte” LOC, met je vreemde manier dat komt nog steeds neer op 1000 euro per LOC. Of omgerekend een dag van een programmeur werk per return statement, een dag om { te typen een dag om een wit lijntje te typen.

Als je denkt dat iemand dit allemaal handgemaakt in VIM heeft, dan bied ik jouw bedrijf graag een 20M euro project aan.
Je kijkt serieus te makkelijk en rooskleurig naar het geheel. Ik heb een unittests geopend en ik zie geen gegenereerde code.

En nogmaals, je gaat er van uit dat alle lijnen code maar één keer geschreven zijn, alsof het allemaal in beton gegoten is/was, nooit een PR is geweest of zelfs maar één refactor slag (ja ook tijdens nieuwbouw kan je dat hebben). 20 miljoen delen door het aantal lijnen code is niet hoe je dit moet terug berekenen. Het is alsof je bij een nieuwe auto het aantal daadwerkelijk gereden kilometers gaat tellen en delen door de aanschafkosten van de auto. Dat zijn hele dure eerste 1000 kilometers ;).
20M-30M is de kost open het einde van een groot software project, niet het begin.

De huidige staat van code is het begin, een paar weken werk voor een klein team. Niet 5 jaar werk en 30M euro, geen enkele serieuze developer die dit kan zeggen.

Wat jij zegt om de analogie te behouden is dat je bij een fabrikant een auto bestelt en dan komt hij 5 jaar later maar enkel met het chassis aanzetten en dan moet jij als de betaler blij zijn met het werk en je geld niet terugvragen?

Dit project volgens de COCOMO II berekening als het volledig handgeschreven was ongeveer 600k euro waard. Hierbij tellen we alle code, incl. de geïmporteerde libraries zoals pdfjs en meer dan 10k SLOC dat niet door de overheid geschreven is.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 15:22]

Vanaf het begin van een project heb je na 2 werken nog niet eens het team bij elkaar die de documentatie moet schrijven om de aanbesteding op de markt te zetten.

Een als je al zover bent dat je kan beginnen heb je de eerste sprint al nodig voor het voorbereidend werk, nog geen lijn code geschreven.

Je overdrijft, niet en beetje maar extreem veel. Het enige wat je in een paar weken tijd kan doen is een poc laten zien. Maar goed, als jij dit in 2 werken kan, start je eigen bedrijf op en ga aan de slag als dit allemaal zo simpel is.
Aanbesteding? Dit was toch allemaal intern? Daarnaast als je toch een groep programmeurs voltijds voor je werken moet je ze maar samen zetten, als je in 2 weken alleen maar vergaderingen en projectplannen heb je wel een enorm slechte planner. Waar ik werk is het een paar maal met de klant vergaderen, de projectmanager schrijft een voorstel en dan zien we noch de manager noch de klant niet meer voor een paar weken.

Dit is miljoenen NA ze al wisten wat ze moeten maken. Zelfs al duurt het 2 maanden, dat komt nog steeds niet op n miljoen, je kunt schattingen en reken systemen adhv SLOC vinden inclusief project management.
Aanbesteding? Dit was toch allemaal intern?
Dat denk ik niet, als je ergens voor "betaald" zou ik zeggen dat het door een externe partij gemaakt is. Als de "kosten" 20 miljoen zijn, dan zou het intern zijn. Maar je hebt wel gelijk dat het nergens vermeld staat en dat ik die aanname doe.
Waar ik werk is het een paar maal met de klant vergaderen, de projectmanager schrijft een voorstel en dan zien we noch de manager noch de klant niet meer voor een paar weken.
Dit is wel heel erg verkort en heb ik persoonlijk nog nooit meegemaakt. Voor een poc of een hackathon, ja. Voor een project van deze omvang, nee, dit doe je niet met en handjeklap en een paar vergaderingen. Dit is een miljoenen project waar enorm veel tijd is gaan zitten nog voordat er een regel code werd geschreven. Bij de omvang en het maatschappelijk belang van dit soort projecten heb je echt te maken met stapels papieren waar je doorheen moet. Al het geld koppelen aan de geleverde code is dan ook niet helemaal terecht en onrealistisch, en dat is het punt wat ik probeer te maken.
Maar ik kan mij haast niet voorstellen dat ze al bij het stukje 'training en opleiding waren', laat staan dat er al een (productie) omgeving was.

Er zullen vast servers zijn gehuurd, maar wat ik op eerste oogopslag zie, is een soort boilerplate, waarbij bakstenen nooit (goed) zijn gelegd. Verder gebruiken ze zo te zien ook open source oplossingen, dus niet alles heeft een licentie.

Nee, er hebben gewoon mensen goed aan verdient, niets-meer niets-minder. Het is gewoon lachwekkend als je leest 'zoekmachine was niet goed'. Er zijn tegenwoordig tig (open source) search-engines, er zijn oplossingen beschikbaar.. gebruik die! Er zijn authentcatie systemen.. (a.u.b.) gebruik die! Waarschijnlijk was er al een systeem beschikbaar, ze hadden zelfs met cloud diensten kunnen werken, waarbij de garantie was/is dat deze enkel voor hun beschikbaar zijn.

De minister (en zijn personeel) hadden de voortgang moeten blijven bewaken, niet jarenlang (ons) geld gooien in een diepe put.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 15:22]

Maar ik kan mij haast niet voorstellen dat ze al bij het stukje 'training en opleiding waren', laat staan dat er al een (productie) omgeving was.
Trainingen zul je echter al vorm moeten geven voor je in productie gaat, en ook daar gaat geld in zitten.
Ja, maar het lijkt me niet realistisch dat ze daar al waren.

*Ik baseer mijn mening wat op GitHub staat.
En vergeet communicatie niet; bestandsnamen veranderen (denk aan logischer/minder ambtelijk maken, zonder evt. nummering), metadata verwijderen (vooral de naam verwijderen van degenen die eraan hebben gewerkt), onder welke categorie(ën) moet een bestand te vinden zijn (ook bij AI een dingetje...)

[Reactie gewijzigd door Janbraam op 22 juli 2024 15:22]

(ook bij AI een dingetje...)
Wel dingetje?
Ontwerpen is ook vaak een kostbaar proces. Vooral als ze eigenlijk niet weten wat ze willen en het veel heen en weer gaat voordat een definitief ontwerp bepaald wordt.

Men geeft vaak consultants de schuld dat dingen duur worden, maar vaak weten bedrijven nog niet wat ze willen totdat ze weten wat ze niet willen.

[Reactie gewijzigd door Martinspire op 22 juli 2024 15:22]

Het is maar een deel van het plaatje maar dit zie je ook terug in de documenten die @keesface hierboven linkt.

Het venijnige, en dit zie je vaker, zit hem onder andere in het feit dat wetten te globaal zijn om functionele en dus ook technische specificaties uit af te leiden.
In de ontwikkelfase heb je geen groot serverpark nodig dus het merendeel van de kosten moet toch echt zijn opgegaan aan ontwikkeling, projectmanagement en overheidstaken.
Ja daar denk je zo ook niet echt aan maar wel logisch. Weer wat geleerd 👍😉
Vergeet niet dat andermans code in de ogen van iemand anders bijna altijd ‘slecht’ is. We denken allemaal dat we betere code schrijven dan iemand anders.
Nee hoor.. ik kijk vaak op Github en denk dan 'wow, zo kan je het dus ook schrijven!' of 'goh, wist niet dat dit kon'. Ook genoeg tools die ik tegenkom, maar gewoonweg geen tijd heb om ze te proberen, en die zitten verdomd goed in elkaar.

Ja, de algemene gedachte blijft veelal 'mijn code werkt beter', maar ik zie toch steeds meer gaan naar open source en die tools dan gebruiken om een product af te leveren voor de klant. De bedoeling is dat je het dan wel weer teruggeeft, als in PR's of sponsoring.

De gedachte van zelf het wiel uitvinden, moet maar eens gaan verdwijnen. Tenzij je echt weet dat jou stukje software iets unieks is.
Ik lees ongelofelijk vaak code van derden waardoor ik denk 'oh goeie, ga ik ook zo doen'. Ik denk bij deze code en dit project, zelfs met meerdere managementlagen en (voor)rondes vooral: hoe kan DIT met enige goede bedoelingen aanwezig OOIT 28 miljoen kosten??? Degenen die de bemiddeling deden of dit hebben binnen gehaald moeten zich blauw hebben gelachen.
Ik kan zelf geen code schrijven, dat wat mij betreft is iedere andere code beter als wat ik zou proberen :+
Code is slechts een klein deel van een product.
Mee eens, de code is niet best. Het is een rommeltje, vaker gezien bij Java projecten, Jammer.
Waarom is er zoveel Java bij (semi-) overheid. Ik heb nooit de aantrekkingskracht in Java gezien, niet omdat ze nogal log zijn, maar dacht dat .NET bijvoorbeeld meer in trek was.

Ik ben meer persoonlijk van webtech, zoals nodejs.
Waarom zouden ze geen Java gebruiken? Het is een ontzettend solide taal voor de grotere applicaties. En het ecosysteem aan libraries in Java valt echt niet te overschatten. .NET heeft niet zoveel meerwaarde behalve voor Windows desktop applicaties. Verder liep Java een tijd wat achter in taalfeatures maar dat is nu bij Java 20 ook echt niet meer zo, vanaf Java 8 al prima te doen weer. Voor Java 8 zijn wij bij mijn vorige bedrijf ook overgestapt naar Scala maar dat was daarna echt niet meer nodig.
.NET is tegenwoordig gewoon cross platform en heeft met NuGet een prima extension ecosysteem. Dat het alleen voor Windows waarde heeft is daarmee achterhaald.

Uiteindelijk komt het gewoon neer op voorkeur, maar kan je met beide talen (en vele anderen), hetzelfde bereiken.
Ik zei dan ook geen waarde, maar meerwaarde. Want verder kan je met Java natuurlijk ook al cross-platform. Maar inderdaad, met .NET kan je ook prima uit de voeten, alleen er is geen goeie reden om dan over te stappen. Dat was ooit pre-Java 8 wel gewoon omdat C# bijvoorbeeld hele leuke language features had die Java mistte, maar dat is nu grotendeels ook niet meer zo.
Voor zover ik altijd heb begrepen is Java vooral populair bij ontwikkeling van het back-end gedeelte van software projecten. En omdat het ooit populair was hebben veel (grote) bedrijven nu een legacy code-basis in Java, welke specifiek voor hun processe en werkwijzes is gebouwd. En dat betrouwbaar doet. Onderschat dat laatste vooral niet.

Onderhoud en uitbreiding van die code-basis is daarom de reden dat er nog altijd volop vraag is naar Java-ontwikkelaars. En dat zal ook nog wel even zo blijven. Matematisch is Java ook sterk in.

Er draait ook nog steeds een heleboel FORTRAN en COBOL code op servers die behoorlijk belangrijk zijn. In het bankwezen, vooral bij internationaal geldverkeer zit nog altijd van die oude meuk.Probleem is dat die code uiterst betrouwbaar is, want er hebben een heleboel heel slimme mensen aan gewerkt en dat heeft banken goed geld gekost.

En met die nieuwe talen is men gewoon minder zeker dat dezelfde mate van betrouwbaarheid gehaald kan worden en hoeveel geld ze daarin moeten pompen om daar zeker van te zijn. Dat zijn kosten die je liever niet wil maken als je al een werkend stuk software hebt.

Dit mag in jouw en mijn ogen een achterhaalde opvatting zijn, het is tevens niet onze beslissing. Modernere talen zijn beter geschikt voor een heleboel zaken. Je vind er ook makkelijker programmeurs voor. Microservices zijn een betere manier van aanpak dan monolitische code-basissen. Hoef je mij ook niet uit te leggen.

Maar ja, zolang we niet op de stoel(en) zitten waar het budget voor word bepaald, is betrouwbaarheid van een code-basis een zeer zwaar wegend argument om door te gaan met de code-basis die men al heeft en werkt cq. waarmee men winst kan draaien.
Als ik om mij heen kijk wordt er op het ogenblik ook nog heel veel in JavaScript gebouwd. Een taal die even oud is als Java.
Uit welke cijfers blijkt dat overheidsprojecten met name worden vertaald in Java? Welke taal en ecosysteem zou jij dan aanraden en met welke onderbouwing?

Java, C# (.NET) of welke OO taal dan ook maakt onder aan de streep niet zoveel uit (if then else). Managed vs Unmanaged, Strongly vs Weakly -typed, Functional vs Object Oriented heeft mogelijk veel meer relevantie . Het verschil zit met name in het ecosysteem, community, support (LTS) / betrouwbaarheid.

Ik zie veelal dat de kosten direct worden gerelateerd aan het stukje code, het wordt een project genoemd voor een reden. In meeste gevallen zitten de echte kosten niet in het schrijven van een stukje code, dit is vaak maar een relatief klein onderdeel van een zogenaamde ICT project.
Mij maakt het niet zoveel uit in welke taal het is geschreven, als het maar werkt. :)

*wel met talen die nog onderhouden worden en waar ontwikkelaars voor zijn
Sinds 2000 is Java de standaard taal die je leert op ICT opleidingen. Dat zal een rol spelen.
Ik leerde standaard Python en C#, er is niet iets als een standaard taal.
Het is een tool met bepaalde eigenschappen. In de enterprise omgeving wordt er vaak gekozen voor een strongly typed en managed taal, niet omdat we dit mogelijk leren tijdens een educatie maar door de eigenschappen.

Persoonlijk vind C# op het gebied van syntax en library design beter uitgewerkt dan Java, alhoewel Java de laatste jaren hard aan het groeien op dit gebied. De doorslag om hoofdzakelijk te kiezen voor Java is het ecosysteem, community en opensource cultuur. En daarbij qua infra en onderliggende fundatie vind ik (L)inux een must voor verschillende redenen.

.NET core heeft zijn mogelijkheden maar staat niet echt in verhouding tot het ecosysteem van Java.
Rommeltje? Dit is 20M+ aan “werk”. En het grootste deel van de code is letterlijk een laagje op de Solr API om te doen alsof dat het een custom API is (met een hoopje bugs geïntroduceerd in oa datums)
private static searchWaardelijst = (waardelijst: any, organisationCode: string)

[/cringe]
Ik ben heel benieuwd naar die "werkbestanden van het ontwikkelproces". Dat zal wel de .git folder zijn aangezien ik de volgende regels tegenkom in de Readme.md in de portaal/plooi-portal-xslweb folder:

This project is a copy of koop-zoekservice, taken at commit 04ff45cd583580a18adf34a413a56e7fb12ac762.
Copying is a workarount, because Gitlab upload has a problem with some big files in the repository.

Ik heb het project even snel gecloned, in Intellij geopend, en met de statistics plugin even snel naar de hoeveelheid code gekeken. Ik weet dat Lines Of Code (LOC) een erg slechte maatstaf is voor die complexiteit van een programma maar de volgende nummers zijn wel erg bedroevend:

De gemiddelde lengte van een java bestand is 67 regels over 508 bestanden. De bestanden met de meeste regels zijn grotendeels automatische tests. Ook belangrijk maar dus geen functionaliteit.

javascript lijkt iets beter initieel met een gemiddelde lengte van 3698 regels(!) over 23 bestanden maar dit is bijna allemaal van de pdfjs library van Mozilla. Het grootste niet-library bestand is 92 regels.

Qua code zijn er dan als laatste nog een aantal ts en tsx bestanden van gemiddeld 41 regels over 179 bestanden en 51 regels over 205 bestanden respectievelijk.

Zoals al eerder gezegd is het aantal regels niet een heel goede maatstaf en het gemiddelde zegt ook niet zo veel over de verdeling van de code over de bestanden maar als ik er zo een beetje doorheen spit dan is het op een paar bestanden na erg leeg.

Voor zover ik kan zien is dit ook alleen een frontend dus ik hoop dat de backend nog ergens anders staat. Zelfs dan is het voor 28 miljoen wel erg karig.
Er zit ook java-backend code in hoor.
hopelijk zijn er die er bronnen bij hebben, maar voor mijn gevoel zit er, zeker bij grote projecten, maar een heel laag % van het budget in daadwerkelijke code kloppen. Ik gok zo op 10%.
Er wordt veel geld gespendeerd aan pre meeting e.t.c en te weinig aan code reviews. Bij veel meetings is er daadwerkelijk maar 30-40% gebruikt om aan het plan te werken. De luidruchtigsten zijn het meeste aan woord en zeggen weinig; maar de innovatieve die luisteren zeggen te weinig en woorden niet gehoord.

Persoonlijk vind ik de manier zoals ze bij het ontwikkelen ( als voorbeeld ) van b.v Swift taal ontwikkelen wel prettig. Er is een API werkgroep, code groep, acceptatie groep. Persoonlijk zou ik het op hoog overheids niveau ( niet politiek ) een deels open source werkgroep willen hebben die voor iedere overheids of gemeentelijke instantie de initiële ontwerp ontwikkelen, API bepalen, e.t.c ( niet de noodzaak van de appl, dat is politiek ). Ze kunnen Open Source modulen ontwikkelen die dan standaard als basis gebruikt kunnen worden i.p.v iedere keer weer het zelfde wiel ontwerpen. Zo kan dan ook beperkt worden wat voor informatie noodzakelijk is om uit het BSN register te trekken.

Maar ja, ik droom verder.
Hoewel er inderdaad veel gepraat wordt bij de ontwikkeling van een programma zet jij het hier wel erg tendentieus neer.
Ik vermoed dat bij elk groot bedrijf met veel vestigingen en belangen er niet veel minder vergaderd wordt.
Daarnaast zijn overleg en vergaderingen ook nodig. Anders wordt de ontwikkeling van je code helemaal een ramp.
Er word veel gepraat voordat er ontwikkeling plaats vindt. Zowel in het bedrijfsleven als binnen de overheid gaat het gros van de tijd (en budget) naar praten voordat men met de ontwikkeling begint. En met ontwikkeling bedoel ik niet code kloppen, ik bedoel daarmee de daadwerkelijke probleem analyse, oplossingsverkenning, etc. waarbij ook de technische mensen betrokken die het daadwerkelijk gaan realiseren en ondersteunen. Vooral dat laatste vergeet men nogal vaak binnen de overheid.
Exact. Heb als externe bij softwareprojecten bij de overheid gezeten en er mist heel veel technische kennis in het voorlooptraject waardoor bij voorbaat al technische keuzes gemaakt worden die tot veel meer extra werk leiden of later weer ongedaan gemaakt moeten worden omdat ze conflicteren of gewoonweg onmogelijk zijn.
Ik ben aan het spitten geweest in de broncode maar echte business logic heb ik niet kunnen vinden. Lijkt voornamelijk veel boilerplate zonder inhoud.

Heeft iemand anders wel iets kunnen vinden?
Ik ben aan het spitten geweest in de broncode maar echte business logic heb ik niet kunnen vinden. Lijkt voornamelijk veel boilerplate zonder inhoud.

Heeft iemand anders wel iets kunnen vinden?
Het is een vrij common omschrijving, vanuit een vrij moderne license, eupl.

Die heeft bar weinig jurisprudentie. Wat zoek je?

https://commission.europa...n-union-public-licence_en
Ja, ik snap er ook niet veel van.

Ik zie iets staan over de Authenticatie-service, maar er ontbreekt van alles. Of het was niet gebouwd, of het is (weer eens) niet volledig vrijgegeven.

28 miljoen.. had het naar zoveel betere projecten en doelen kunnen gaan. Wie is er rijk geworden van dit stukje 'software'? Soms vraag ik mij af, waarom ben ik niet voor de overheid gaan werken?
Ik zie toch duidelijk een spring-security impl voor de afhandeling van een token-based authenticatie, wat ontbreekt er dan precies aan? De IDP zelf is in alle waarschijnlijkheid gewoon een aangekocht product.

Misschien wel iets teveel maatwerk voor mijn smaak maar goed details details, en zonder kennis van de situatie en context waarom en hoe deze code tot stand is gekomen heb ik er ook niet echt meteen een oordeel over.

[Reactie gewijzigd door hermensb op 22 juli 2024 15:22]

Ik zie in aanleverloket-v2 een gigantisch complexe frontend staan, aannemende dat die niet automatisch is gegenereerd. Zo'n beetje elk element dat in je browser is ingebakken wordt opnieuw gedefinieerd maar nu in React. Ook de map "verwerken" heeft aardig wat broncode.

De rest lijkt een combinatie van Dockercontainerconfiguratie en wat kleine XLSX-services te zijn.
Mij leek dat een deel van de frontend ook door XSLT gedaan te worden.
Dat is grotendeels React boilerplate. Als je een React app bouwt met een paar libraries en een IDE is een groot deel auto-generatie, daarom dat er oa geen comments instaan en de rest van de code is zoals de Java code, doen alsof je code schrijft maar gewoon de API die je al hebt herimplementeren. Zoals dit lijntje:

public getItems(): WaardelijstItem[] {
return this.items;
}

public getCount(): number {
return this.items.length;
}

public addItem(item: WaardelijstItem): void {
this.items.push(item);
}

Etc etc, elke functie die je kunt uitoefenen op een array opnieuw geïmplementeerd met een enkele lijn code.
Over de ontwikkeling van de Corona app is natuurlijk veel gesproken. De open manier van aanbesteden en ontwikkelen is een testcase geweest die niet helemaal vloeiend is verlopen. Deels omdat men zich nauwelijks voorbereidingstijd heeft gegund.
De app is uiteindelijk minder gebruikt dan gehoopt, maar men heeft de campagne om het gebruik te bevorderen ook achterwege gelaten.
Los van het succes of gebrek daaraan is het wel een goede testcase geweest voor de manier waarop de overheid in de toekomst met nieuwe projecten om wil gaan. Met de Corona app zijn misschien wat miljoenen verspild, maar die kan men door de meer open-source gerichte ontwikkeling dubbel en dwars terug verdienen. Wat dat betreft vormde de corona app een mooie testcase. Het was immers "maar" een los staand systeem dat toch maar voor tijdelijk gebruik zou zijn.
Er zitten veel partijen met allemaal belangen in en rond de overheid. Kijk bijvoorbeeld maar eens voor de grap naar Zembla of zoek eens op hoe bepaalde partijen/personen/bedrijven alles voor elkaar krijgen.

Ik ben stiekem voorstander ervan dat overheidsmensen aansprakelijk kunnen worden gehouden voor dingen die ze niet of fout doen. Deze 28 miljoen (wat een bedrag) bijvoorbeeld, dat 'verdwijnt' gewoon en zien we niet meer terug. Als ik op mijn werk zaken laat verdwijnen of niet productief ben (*als ik er met de pet naar gooi), dan krijg ik ook problemen. Waarom komen er mensen mee weg?

Hier zal wel weer over X jaar een commissie voor komen, waarbij zaken alweer zijn verjaard of mensen het zijn 'vergeten', want het was toch wel een tijd geleden.

Ik kan mij er zo boos over maken, vooral als je dan hoort dat er voor bepaalde zaken geen geld is.
De competente mensen rennen gillend weg bij de overheidsafdelingen waar ik als externe gezeten heb en de overgebleven mensen worden niet getraind en zeer slecht aangestuurd. Tel daar bij op een dikke lasagna van managementlagen die weinig waarde toevoegen en vooral de laag boven zich proberen te vertellen dat alles goed is en je hebt een perfect recept voor veel verspilling.
En tel de Tweede Kamer daar ook bij op, die vaak om de haverklap nieuwe en onuitvoerbare regels en wetten bedenken. Ga daar maar eens mee dealen.
Soms zelfs conflicterende regels in wetten en richtlijnen die het onmogelijk maken aan beide tegelijk te voldoen waar daar wel noodzaak voor is.
In een bedrijf ben je toch ook niet persoonlijk aansprakelijk?

Zijn massa’s voorbeelden van commerciële producten die vrijwel af zijn, maar nooit echt op de markt gekomen zijn. Dan zijn er ook miljoenen in rook opgegaan. Hoeveel geld precies weet je niet, omdat ze geen publieke verantwoording af hoeven te leggen.

Het gaat niet helpen om mensen persoonlijk verantwoordelijk te houden, dat risico willen mensen nooit nemen als ze elders minder risicovol werk kunnen doen, met vergelijkbaar salaris.
Misschien is een blunderende werknemer niet hoofdelijk aansprakelijk, maar grove fouten maken heeft in het bedrijfsleven wel consequenties. Bij de overheid zie ik dat helaas niet vaak.
Wel als ik geld investeer en dat niet kan verantwoorden. Het is niet dat ik met de bedrijfscreditcard allemaal aankopen mag doen, of geld mag uitgeven aan externe partijen/partners zonder enige verantwoording.
Dat is bij de overheid echt niet anders, bv tot 250 mag je zelf doen, tot 2500 met goedkeuring van je manager, tot 20k het afdelingshoofd enz.
Wel hebben inderdaad al 2 van die commissies gehad, rond 2003 en in 2012. Na afloop wordt er een mooi rapport overhandigd en dat wordt in het archief opgeslagen. Verder is er met de aanbevelingen niets gedaan volgens Ton Elias (voorzitter van de onderzoekscommissie in 2012)

https://nl.wikipedia.org/...projecten_bij_de_overheid
Ook bij de overheid worden mensen gewoon verantwoordelijk gehouden voor hun daden (of gebrek daaraan).
Wie slecht presteert wordt uiteindelijk ook van zijn functie ontheven en ontslagen of herplaatst.

De ICT is een heel vreemd onderdeel. Daar praten mensen met te weinig verstand van zake over wat zij denken wat nodig is. Als het werk eenmaal is begonnen veranderen de wensen en eisen eigenlijk continu. Dat kunnen best ingrijpende zaken zijn. Achteraf is het best mogelijk om nog een dakkapel op een huis te zetten, maar tijdens de bouw alsnog een kelder onder het huis bouwen is behoorlijk gecompliceerd. Dit soort grote aanpassingen worden wel gevraagd.
Ik vind het wel apart dat de code een mix is van Engels en Nederlands. Dat maakt het niet beter leesbaar.
De API specs en definitie zijn helemaal in het Nederlands, zie als voorbeeld https://koop.gitlab.io/pl...on/createMetadataInstance. Met JSON velden als creatiedatum.

Ik vind dat een aparte keuze, zeker in de tijd. Je kan nu eigenlijk bijna alleen Nederlands sprekende ontwikkelaars gaan aannemen. Voor de server zelf kan je nog discussiëren of dit een gewenst effect is. Meer kennis in NL houden is niet slecht, maar het is ook zo generiek opgezet dat ik het nut niet zie. Voor overheden die dan zelf met de API zouden integreren geldt hetzelfde.

Is hier een wetgeving voor of wat dit eigen inzicht van de ontwikkelaars?
Er is van hogerop veel druk om alles in het Nederlands te doen, maar er worden regelmatig developers ("bouwers") ingehuurd met een niet-nederlandse achtergrond waardoor je deze unieke mengeling krijgt.
Of er zijn nieuwe ontwikkelaars aangetrokken die zich niet aan die "programmeer in NL"-eis houden. Want niet onthouden, niet afgedwongen en/of niet gecorrigeerd.

Mijn vorige project ook. Er was een requirement om het in NL te doen. Halverwege het project was er een collega die wat liet zien, de vraag kwam "waarom is het in het engels?" -> "zo werken we hier toch?" -> "nee, alles is in NL" -> "Oh". Maar die collega en zijn team hebben dat niet gecorrigeerd.
Plus op een gegeven moment waren de ontwikkelaars het ook een beetje zat (want doorloopAlle ipv forEach is cringy), waardoor er meer in het engels werd gedaan. Dat was ook dat de originele bouwers al weg waren, waardoor dat minder werd afgedwongen.
Je hebt er echt een bepaald slag ontwikkelaars voor nodig die daarmee om kunnen gaan.
Nog erger: project word gebouwd op basis van engelse specs uit Brussel (EU) en het team ontwerpers vertaalt alles naar gebrekkig Nederlands behalve de internationale interface (in XSD). Zo gauw er iets niet duidelijk is en je de specs in moet duiken moet je zelf maar gokken op welke manier er vertaald is.
Soms worden er zoveel Nederlandese afkortingen gebruikt en vakjargon, dat vertalen het niet beter maakt. Ik programmeer zelf ook in het Nederlands en vind het nog steeds cringy. En het is met regelmaat ook een mengelmoes.
Maar als alle documentatie en specificaties allemaal Nederlands zijn.... Ga dat maar eens vertalen.
Maar als alle documentatie en specificaties allemaal Nederlands zijn.... Ga dat maar eens vertalen.
Nee. Zou gewoon niet willen werken op zo'n project.


(documentatie mag nog, velden)
(Gebruiken ze nog StuFF bij de overheid?)

[Reactie gewijzigd door MrMonkE op 22 juli 2024 15:22]

Nog erger: de specs en alle interfacespecificaties komen uit Brussel (EU project) en zijn Engelstalig, maar het team ontwerpers heeft deze halfbakken naar Nederlands vertaalt. Nu heb je dus specs en regelgeving in het Engels, interfaces in het Engels, maar usecases en sommige (!) interne velden in het Nederlands. Recipe for disaster.
De algemeen na mijn weten vertaal je domein jargon niet. Dit is onder meer voor het voorkomen van verwarring, misvattingen en het maken verkeerde vertalingen. Volgens mij name afkomstig uit de DDD hoek. Dus zaken als; /getBeheerContract, /determineBeheerLevel zijn valide, daarentegen geefBeheerContract of bepaalBeheerLevel niet.

[Reactie gewijzigd door hermensb op 22 juli 2024 15:22]

Dit zie je vooral vaak bij (semi-)overheid. Eisen vanuit aanbestedingen of i.v.m. Ambigious Language, DDD, slecht te vertalen vakjargon etc.
Persoonlijk altijd een groot tegenstander van Nederlands programmeren geweest.
Het is ook echt niet meer van deze tijd als je kijkt naar de hoeveelheid niet-nederlandse developers die tegenwoordig ook voor dit soort projecten werken. Het is gewoon niet realistisch om 100% nederlands sprekende mensen in te zetten, die zijn er gewoon niet genoeg.
Als je naar de onderliggende code kijkt is het gewoon een herimplementatie van de Solr backend. Doen alsof je iets nieuw implementeert maar het is gewoon (in pseudo code)

CreatieDatum: return SolrAPI(zoekterm).ok()[creationDate]

Oh ja, en zo krijg je vreemde API fouten en vertraging/overbelasting want je maakt van een asynchronische API een synchronische Solr cliënt op je server zonder error handling ipv het object door te geven naar de cliënt voor het wachten en foutafhandeling.
Misschien had een klein onderzoek welke bestaande open source data platformen al bestaan wat euro's kunnen besparen. Ik denk aan:Een vlugge blik door de broncode deed denken dat het makkelijk was aan de bovenstaande projecten wat te tweaken en doorontwikkelen dan van de grond af aan alles zelf te bouwen.
Of gewoon een goede verkoper inhuren en het (gratis) geld stroomt binnen. Het product hoeft niet af, verantwoordelijk word je toch niet gehouden. :)
De laatste jaren is de overheid een flinke inhaalslag aan het maken wat betreft Open Source. Vanuit Europa gaat hier de aankomende jaren hard op geduwd worden. Ik denk dat dit project iets te vroeg kwam.
Toch mooi om te zien dat het dan gewoon zo online komt. Benieuwd of er nog wat interessants uit komt.
Side note, mijn reactie gaat niet over de code inhoud zelf maar ..

Ik werk voor de (gemeentelijke) overheid in het domein van 'IV-vraagstukken'. Volgens mij was het rondom de kerstperiode van afgelopen jaar, dat bekend werd dat PLOOI zeer waarschijnlijk geen doorgang meer zou vinden. Wat teweegbracht dat diverse leveranciers (van bijvoorbeeld zaaksystemen en DMS-en) hun 'eigen' oplossingen momenteel aan het ontwikkelen zijn. (Al commerciële voorstellen voor gehad), maar ook dat gemeenten zélf werk gaan maken van actieve openbaarmaking van informatie. (Vooral de grotere gemeenten die veelal beschikken over een goede enterprise search engine) Zie bijvoorbeeld open.amsterdam

Dat gezegd hebbende, ben ik benieuwd wat het Overheidsbrede alternatief gaat worden van PLOOI én of men 'de boot ' dan niet al gemist heeft nu gemeenten (..of enig andere overheidsinstantie) zelf alternatieve oplossingen gaan toepassen.
Ik zie nogal wat reacties die zeggen dat dit geen 28 miljoen waard is. Dat klopt, daarom is het ook stil gezet.

Het is moeilijk te beoordelen hoeveel die code wel waard is. Waarschijnlijk is er al een hoop uitgegeven voor de eerste regel code was geschreven.

Toch vind ik het nuttig dat de code is gepubliceerd, zelfs als niemand er ooit gebruik van maakt. Het is namelijk een datapunt dat we kunnen gebruiken om andere projecten en processen mee te vergelijken.
Journalisten kunnen er nu induiken en onderzoek doen naar wat er goed en fout is gegaan en wie daar verantwoordelijk voor is. Er is overigens al onderzoek gedaan (dat is de reden dat het is stilgelegd) maar dat is uiteindelijk die overheid die haar eigen werk beoordeeld. Het is goed als journalisten dat weer onderzoeken en controleren zodat we er van kunnen leren voor het volgende project.
Als je dit zo leest dan denk je toch, dit kan ik beter?

[Reactie gewijzigd door estoniaman op 22 juli 2024 15:22]

Wel als je alleen de code meeneemt in je afweging en de rest van een project negeert.

Op dit item kan niet meer gereageerd worden.