Als je je ontwikkelproces wilt verbeteren zijn er veel standaarden en raamwerken beschikbaar. Eén van de bekendere is de Plan-Do-Check-Act (PDCA) cyclus om continue verbetering te realiseren:

• Tijdens de Plan-fase stel je verbeterdoelen en ontwerp je een nieuwe versie van je proces.
• Tijdens de Do-fase probeer je het nieuwe proces uit.
• Vervolgens evalueer je tijdens de Check-fase de resultaten van het nieuwe proces tegen de gestelde doelen.
• Als de nieuwe processen de gestelde doelen halen neem je die tijdens de Act-fase in gebruik.

Nu heb je een betere versie van je proces en kun je de cyclus opnieuw uitvoeren. Tenminste, dat is het idee. In de praktijk van softwareontwikkeling is de PDCA-cyclus nog niet zo eenvoudig uit te voeren. Het ontwerpen van een nieuw proces leidt al snel tot big-design-up-front en wensdenken. Een enkel softwareontwikkelproject kan lang duren waardoor resultaten lang op zich laten wachten. Nieuwe processen implementeren is sowieso ingewikkeld. En, of een nieuw proces werkt of niet is lastig te evalueren als je organisatie een diverse portfolio aan applicaties en projecten heeft.

Er is echter een pragmatisch alternatief: Do-Describe-Check-Act.

In een tijd waarin digitale overheidsdiensten steeds vaker via REST API’s communiceren, is het waarborgen van de veiligheid van deze interfaces cruciaal. WuppieFuzz, ontwikkeld door TNO, is een open-source, coverage-guided fuzzer die specifiek is ontworpen voor het testen van REST API’s. Het doel: kwetsbaarheden en bugs opsporen voordat ze misbruikt kunnen worden, met een sterke focus op gebruiksvriendelijkheid, modulariteit en inzichtelijkheid.

Je kijkt naar je broncode en denkt: als ik had geweten wat ik nu weet, had ik het anders aangepakt. Een typisch voorbeeld van technische schuld. Wat is het, hoe kun je het voorkomen (niet dus) en hoe pak je het aan?

Sommige developers zweren bij dynamisch getypeerde programmeertalen zoals Python en PHP, sommige bij statisch getypeerde talen zoals Rust en Go. Maar wat zijn nou de grootste verschillen in de praktijk?

Bij de Kiesraad gebruiken ze voor het project Abacus van meet af aan Rust. Daarom toog ik naar Den Haag, waar de Kiesraad huist, om Mark Janssen en Ellen van Leeuwen van Abacus hier eens over uit te vragen.

Mark Janssen: Lead Developer (links) en Ellen van Leeuwen: Software Developer (rechts)

Terwijl software development bij uitstek een werkveld is waarin samenwerking vereist is, kampen veel organisaties met "eilandjesvorming". Teams werken geïsoleerd van elkaar, met weinig onderlinge afstemming. Dit leidt tot een gebrek aan eenheid in het gebruik van technieken, zoals programmeertalen en libraries.

Wat is het resultaat? Een wildgroei van verschillende codebases zonder handleidingen die later onderhoudsproblemen veroorzaken. Ik zet een aantal van de nadelen voor management en developers op een rij.