Teleurstellend dat de applicatie niet bij de eerste identificatie van de bug gewoon aangepast is.

De uren kosten van ambtenaren die corrigeren, communiceren en herstellen is groter dan de bug maken.

Lessons learned: probleem afwenden is duurder, dan probleem meteen oplossen.

Die lessons learned van dat problemen afwenden zo duur is, zal niet doorkomen.

In de project - product owner - cultuur.
- op tijd geleverd = succes
- Klant heeft het geaccepteerd = succes
- Klant kom terug voor weer werk = groter succes
Nergens genoemd is dat de kwaliteit een succes is, niet meetbaar.

De klant bepaalt wat succes is - en als die klant daarin "kwaliteit" (hoe je het ook definieert) niet meetelt - hun keuze.

Is het eigenlijk een bug ? Of een ontbrekend design requirement ? Of het niet omgaan met veranderende omstandigheden ?
(als er iets veranderlijk is - de fiscale/wettelijke regels in randgeval situaties kunnen best snel veranderen )

Ik zou niet al te snel roepen dat de kosten van correctie groter zijn dan het maken van een nieuwe versie - nieuwe requirements, ontwikkeling, testen, acceptatie, uitrol .

Dan ben je je baan kwijt, je hebt geen geld meer, kan niet soliciteren want je bent niet meer integer noch schoon. Allemaal omdat een systeem of een ambtenaar een fuckup maakt en dan komt er even zoon gezellige leuke blonde meid je vertellen dat het leven een feest is maar dat je zelf de slingers moet ophangen.

Leuke sympatieke meid hoor, goede vriendin. Maar dat is naar mijn mening niet hoe het werkt. Ik denk dat 90% van de mensen in de bijstand/achterstand wel zoon beetje dezelfde mening hebt.

Sommige mensen hebben geen riemen om mee te roeien.
Sommige mensen weten niet te roeien met de riemen die ze hebben.
Sommige mensen daar moet je verplicht voor roeien....

In deze is de gemeente met haar applicatie de leverancier, niet de klant. En de gemeente wordt betaald door de overige burgers (eigenaar/opdrachtgever), en staat in dit geval in dienst van de steuntrekkende burgers (=klant).

Over kosten van correctie het volgende inzicht: de applicatie is juist bedoeld om menselijk handelen te vervangen, dat is de toegevoegde waarde en dat mag development geld kosten. Als de applicatie niet functioneert moet 1) de handeling alsnog uitgevoerd worden en 2) de correctie worden uitgevoerd. Dat is dubbel jeugdpuistjes.

(in het voorbeeld ga ik van uit dat de fout regelmatig gebeurt, en niet slechts een kans van 1 op de miljoen)

Ik heb het achterliggende artikel gelezen. daarin: "Vorig jaar is de kwaliteit van alle software van Socrates onafhankelijk getoetst. Daaruit bleek dat deze software stabiel en toekomstbestendig is" en vervolgens de constatering in praktijkvoorbeelden van vele faals en geen registratie van de problemen. Dat is raar.
Alsof er naar enkel naar de code en techniek gekeken is zonder dat proces te evalueren.

Uit hetzelfde artikel

<i>"De gemeente kan het niet herstellen, omdat het computersysteem Socrates is ontworpen voor netto-uitkeringen. De IOAW en IOAZ zijn bruto-uitkeringen."</i>

Ergo, ik lees dat dan maar zo: blijkbaar hebben de gemeentes gekozen om met een hamer een schroef ergens in te slaan, omdat ze de hamer al hadden.

Mijn verdere redenatie is dat 'toen de regelingen kwamen', er weinig tijd / geld was om een beter gereedschap te ontwerpen en dus de hamer uit de kist is getrokken.

En dan zijn we nu verbaasd dat die schroeven 'er niet zo makkelijk meer uitgaan'.

De constatering dat van de lezer hierboven
"Alsof er naar enkel naar de code en techniek gekeken is zonder dat proces te evalueren." is wel terecht, maar een toets op codekwaliteit doet precies ook dat, en doet niet vanzelfsprekend een check of de code nog "fit for purpose" is.

Misschien verwachtte de gemeente dat laatste wel van dat onderzoek, maar ik weet niet wat de opdracht was aan het onafhankelijke onderzoeksbureau.

Zonder al dat soort details te kennen vraag ik me af wat het doel dan is van dit artikel? wat wil je er mee bereiken? meer voer voor de discussie op 1,5 meter over 'hoe slecht de overheid wel niet is'? en wat voor it-gedoe ze iedere keer weten te creeeren?

wellicht hebben ze in de Amsterdamse haven nog wat wal over, voor meer stuurlui...

karma4, op wie ik reageerde, had het deel duidelijk over het software ontwikkel proces .
In z'n algemeenheid - maar daar is de gemeente de klant van de een of andere externe of interne leverancier.

Qua dienstenlevering aan de burger door de overheid is er het vier-jaarlijkse acceptatie moment .


Wat is regelmatig - dat is altijd de vraag wanneer je een workaround / handmatig proces / exceptie introduceert en niet , of niet meteen het onderliggende probleem oplost.
En natuurlijk hoe lastig/tijdrovend/duur een oplossing van het systeem is.

Wie werkelijk in de IT werkt heeft gegarandeerd wel eens een 'preventieve restart' op regelmatige (week ? maand ? kwartaal ?) basis gezien van de één of andere service, server of device vanwege bijvoorbeeld een lastig vindbaar memory leak.
Permanent, of tot de eerstvolgende major upgrade of "ding wordt toch voor het eind van het jaar vervangen, gaan we geen energie meer insteken om dat echt op te lossen" .

Dat zou zomaar zo kunnen zijn, en het is volkomen legitiem om aspecten als de codekwaliteit en onderhoudbaarheid onafhankelijk te laten beoordelen, los van de inhoudelijke/functionele kant van de applicatie. De conclusie kan dan inderdaad zijn dat de software stabiel en toekomstbestendig is in termen van codekwaliteit en onderhoudbaarheid. Het enige rare aan de uitspraak die je citeert is dan dat iemand daarmee schermt alsof het aantoont dat ook functioneel alles klopt.

Toen ik gisteren zocht naar wie deze software eigenlijk ontwikkeld had kwam ik deze infographic tegen, op de website van, als je even verder kijkt, de ontwikkelaar van deze software:
https://www.wigo4it.nl/local/userfiles/documenten/Socrates_infographic.pdf
Daarin staat dat de Software Improvement Group (SIG) de code heeft beoordeeld. Met SIG heb ik alweer meer dan 10 jaar geleden een keer te maken gehad. Hun specialiteit was inderdaad primair het beoordelen van de onderhoudbaarheid van de programmacode, en dat deden ze goed. Dat kan heel goed de onafhankelijke toets zijn die genoemd was.

Het nut van zo'n toets? Als een organisatie zijn bedrijfsvoering afhankelijk maakt van software is, naast de vraag of op functioneel niveau alles deugt, de vraag heel belangrijk of de leverancier niet gaat vastlopen in spaghetticode waarin het moeilijker en moeilijker wordt om nog wijzigingen voor elkaar te krijgen zonder dat allerlei dingen die werkten erdoor kapot gaan. Als de code goed gestructureerd, overzichtelijk van opzet en onderhoudbaar is is de kans groot dat de leverancier dat goed voor elkaar krijgt. Een partij als SIG specialiseert zich in die beoordeling. Bedrijven die zelf software ontwikkelen kunnen de onderhoudbaarheid ervan laten doorlichten, maar ze kunnen ook namens een klant de software van een leverancier beoordelen, er zijn leveranciers die onder NDA hun broncode beschikbaar stellen voor zo'n oordeel. Ik weet niet hoe dat hier is gegaan.

Wigo4it, de leverancier van Socrates, meldt op zijn website vierweekelijkse releases aan te houden zodat wetswijzigingen snel geïmplementeerd zijn. NOS citeert een advocaat die zegt dat Socrates is ontworpen voor netto-uitkeringen, terwijl IOAW en IOAZ bruto-uitkeringen zijn. Socrates is volgens de gelinkte infographic wel degelijk ook voor deze uitkeringen bedoeld. Het zou een ernstige tekortkoming zijn.

Het is de vraag wat hier veroorzaakt heeft dat dit al twee jaar lang fout gaat. Is het inderdaad een ernstig functioneel gebrek in de software? Pakt dan de leverancier signalen erover niet goed op? Zijn het de gemeenten die gebreken niet melden bij de leverancier? Is dat organisatorisch niet goed ingericht? Hebben medewerkers niet door dat er wat aan gedaan kan worden en modderen ze door met software die ze als een gegeven beschouwen waar ze geen invloed op hebben? Of kan de software het op zich wel maar weet een deel van de gebruikers niet hoe je hem goed gebruikt? Er kan van alles aan ten grondslag liggen. Hopelijk helpt wat herrie in de media om de zaak in beweging te brengen zodat duidelijk wordt hoe dit misging en om dit te herstellen.

Ik kan mijzelf voorstellen dat als het een applicatie betreft die bijvoorbeeld foutief een huisnummer plaatst in het veld bedoeld voor de postcode, en het "ding toch voor het einde van het jaar wordt vervangen, het wordt gelaten voor wat het is als een workaround maar doeltreffend en substantieel is; dus niet na herstart de applicatie automatisch de ingevoerde waarde delete omdat het een ongeldige postcode is (4 cijfers, 2 letters)

Maat hier krijg ik de indruk dat de aanbeveling van de IT om deze bug/functiefout op te laten sporen en te repareren door de leverancier al of niet bewust genegeerd is/wordt en dat al bijna 23 maanden (gesteld zo'n preventieve restart per maand) en dat terwijl - dat is de premisse - een ambtenaar dit is opgevallen.

Het valt buiten een directe discussie hier op een IT site, maar ik vraag mij hier toch af waar het spaak loopt in voorkomend geval: De opmerkzaamheid van een ambtenaar, die het meldt aan de IT contactpersoon bij een gemeente; die het op zijn beurt ook doorgeeft aan het gecontracteerde IT service bedrijf, waarna het ernstig gevolg van een softwarefout; mensen worden onder het bestaansminimum geworpen, niet wordt opgevolgd door een doelgerichte reparatie van de 'verantwoordelijke' software.
Iemand moet de aanbeveling tot reparatie, gesteld door het IT servicebedrijf, niet hebben gehonoreerd.
Daardoor ontstaat meteen weer de bevestiging van de veronderstelde laconieke overheid die het vertrouwen van de burger niet (meer) verdiend.

Daarom vind ik de reactie van de drie andere gemeenten die ongetwijfeld deze bug óók moeten hebben geconstateerd (daar werken ook opmerkzame ambtenaren) zo stuitend.
Niet alleen ten opzichte van de burger maar ook ten opzichte van zichzelf. Hier is het: "Wij herkennen onszelf daar niet in" op zijn minst een degradatie van deze uitspraak (om mij voorzichtig uit te drukken)

Gemeenten zijn gebruiker van de applicatie, niet de bouwers. De verdere toevoegingen zijn volstrekt irrelevant. Bij de vraag wie leverancier is, en wie klant is, m.b.t. deze software.

Indien een bedrijf software laat maken, dan ga je ook niet zeggen dat dat bedrijf de leverancier is, en de aandeelhouder van het bedrijf de klant. Waarbij je werkelijke leverancier/bouwer negeert.