Door Tweakers Partners

Dev Summit 2026: waarom legacy volgens Stefan Koopmanschap geen scheldwoord is

24-09-2026 • 08:00

15

Nieuwe software krijgt alle aandacht: budget, planning en lancering. Daarna begint het minder zichtbare werk: zorgen dat ze veilig en bruikbaar blijft. Juist daar gaat het volgens Stefan Koopmanschap vaak mis. Tijdens de Tweakers Developers Summit 2026 spreekt hij over Lifecycle Management: de waarde van up-to-date software. Zijn boodschap: software is geen eenmalige aankoop die je na oplevering kunt vergeten.

Net zoals een architect bij het ontwerp van een gebouw al nadenkt over toekomstig onderhoud, moet ook de architectuur van software ruimte bieden aan updates, nieuwe versies en veranderende omstandigheden. Toch ziet Koopmanschap steeds opnieuw systemen die jarenlang nauwelijks zijn bijgewerkt. Dat raakt niet alleen de techniek, maar ook de veiligheid, prestaties, kosten en uiteindelijk de toekomst van een organisatie. Tijdens zijn talk laat hij zien hoe teams kunnen voorkomen dat een kleine achterstand uitgroeit tot een peperduur reddingsproject.

Programmeren voordat downloaden bestond

Koopmanschap is al bijna dertig jaar actief in de softwareontwikkeling. Zijn fascinatie voor computers begon echter nog eerder, thuis in Apeldoorn, waar het gezin een Acorn Electron had.

Zijn vader gaf hem een geprinte handleiding voor BASIC. "Want downloaden was toen nog niet een ding", vertelt hij met een lach. Op iedere computer die daarna in huis kwam, probeerde hij wel iets met code te doen. Aanvankelijk bleef dat bij experimenteren en spelen, maar tijdens zijn opleiding werd het serieuzer. Een collega tijdens een stage zag dat hij websites in HTML bouwde en wees hem op PHP. Daarmee hoefde hij niet langer iedere losse pagina aan te passen wanneer een website veranderde.

Die tip bepaalde voor een belangrijk deel zijn loopbaan. Koopmanschap probeerde verschillende programmeertalen, maar kwam steeds weer bij PHP uit. Zestien jaar geleden begon hij samen met zijn vrouw Marjolein het bedrijf Ingewikkeld. Wat begon met het beschikbaar stellen van PHP-developers, groeide uit tot een bedrijf voor softwareontwikkeling, consultancy, trainingen, advies en interim-leiderschap. Marjolein richt zich meer op communicatie en ontwerp, Stefan vooral op de techniek. Al benadrukt hij dat programmeren óók een creatieve manier van werken is.

Legacy is geen scheldwoord

Als externe specialist komt Koopmanschap vaak bij bedrijven met een omvangrijke, oudere codebase. In de ontwikkelaarswereld krijgt zulke software al snel het etiket 'legacy'. Dat klinkt meestal niet als een compliment: het suggereert verouderde techniek, ondoorzichtige code en keuzes die een developer van nu nooit zou maken.

"Legacy is altijd wel het deel van je software waar het geld mee verdiend wordt."Koopmanschap kijkt daar anders naar. "Legacy is altijd wel het deel van je software waar het geld mee verdiend wordt." Het is de geschiedenis van een bedrijf én zijn erfenis. Achter de soms rommelige code zitten processen en functionaliteit waarop klanten en medewerkers iedere dag vertrouwen. Dat maakt de software juist bedrijfskritisch.

Hij herkent ook een typisch menselijke reflex bij developers. Oude code is vaak geschreven door iemand anders en wordt daardoor al snel minder goed gevonden dan de eigen oplossing. Of, zoals hij het droog formuleert: "Het is over het algemeen de code die geschreven is door een andere developer, dus dan is het sowieso minder goed dan wanneer je het zelf zou schrijven."

Dat betekent niet dat oude systemen met rust moeten worden gelaten. Juist omdat organisaties ervan afhankelijk zijn, moeten ze voorkomen dat hun belangrijkste software onhandelbaar wordt. Koopmanschap en zijn collega's treffen geregeld applicaties aan waarvan zowel de frontend als de backend vele versies achterloopt. Een groot deel van die achterstand is volgens hem te voorkomen.

Management én developers spelen een rol

Hoe komt het dan dat bijna iedereen het belang van updates begrijpt, maar zoveel organisaties toch achterlopen? Koopmanschap ziet oorzaken aan beide kanten van de vergadertafel.

Bij het management leeft nog te vaak het idee dat software vooral een eenmalige investering is. Er wordt geld vrijgemaakt voor de bouw en na oplevering moet het systeem het vervolgens gewoon blijven doen. "We doen een eenmalige investering in software. En dan blijft het wel draaien. Dat is gewoon niet hoe het werkt.""We doen een eenmalige investering in software. En dan blijft het wel draaien. Dat is gewoon niet hoe het werkt."

Software staat nooit stil. Library's en frameworks verschijnen in nieuwe versies, koppelingen veranderen en beveiligingsproblemen worden ontdekt. Onderhoud moet daarom geen onverwachte tegenvaller zijn, maar een vast onderdeel van de levenscyclus en de begroting.

Developers gaan volgens Koopmanschap evenmin vrijuit. Onderhoud aan bestaande systemen klinkt nu eenmaal minder aantrekkelijk dan iets nieuws bouwen. "Developers hebben heel vaak eigenlijk helemaal geen zin om aan die oude software te werken. Die willen nieuwe dingen bouwen, en het liefst met mooie, shiny, nieuwe technologie."

Zo versterken beide groepen hetzelfde probleem. Het management geeft voorrang aan zichtbare nieuwe functies, developers werken graag met moderne technieken. Het noodzakelijke onderhoud verdwijnt naar de achtergrond, terwijl de technische achterstand blijft groeien.

Kleine updates voorkomen een grote sprong

Volgens Koopmanschap hoeft lifecyclemanagement helemaal niet ingewikkeld te zijn. De basis is juist overzichtelijk: wacht niet jarenlang, maar werk de software regelmatig in kleine stappen bij. "Kleine stapjes is altijd makkelijker dan een hele grote sprong."

Een beperkte update is doorgaans goed te overzien en te testen. Wie meerdere jaren overslaat, krijgt te maken met een stapeling van veranderingen. Dan dreigt vrijwel het volledige softwarepakket op de schop te moeten. Dat kost meer tijd, brengt grotere risico's mee en maakt fouten lastiger te vinden.

Organisaties moeten daarom bewust ruimte inbouwen voor onderhoud, niet alleen wanneer een ernstig lek of een storing zich aandient. Die investering is minder zichtbaar dan een nieuwe functie, maar voorkomt later een veel duurdere en ingewikkeldere migratie.

Koopmanschap zegt het met de nodige zelfspot: organisaties kunnen beter geregeld kleine upgrades uitvoeren, "zodat je dat niet na vijf jaar voor veel geld ineens door een externe moet laten doen, zoals ik."

Hoe teams dat onderhoud organiseren en hoe developers en leidinggevenden elkaar daarbij kunnen helpen, bewaart hij grotendeels voor zijn presentatie. Wel belooft hij concrete handvatten waarmee bezoekers zelf aan de slag kunnen.

Achterstallig onderhoud raakt meer dan security

Bij verouderde software denken veel mensen als eerste aan beveiligingslekken. Dat is terecht, maar volgens Koopmanschap is security slechts één onderdeel van het verhaal. Een achterhaalde stack kan ook slechter presteren, problemen geven met andere systemen en verhinderen dat developers moderne functies gebruiken.

Bovendien groeit met iedere uitgestelde update de afstand tot de huidige standaard. Ondersteuning voor oude versies kan stoppen en nieuwe medewerkers moeten zich verdiepen in technieken waarmee ze elders nauwelijks nog werken. Zelfs een kleine wijziging kan daardoor steeds meer tijd kosten.

Het besef is bij veel organisaties wel aanwezig. Developers en managers zeggen vrijwel allemaal dat onderhoud belangrijk is, maar zodra ze prioriteiten moeten stellen, wint het nieuwe meestal van wat al bestaat. Koopmanschap ziet het als zijn taak om die vanzelfsprekendheid te doorbreken. "Het houdt mij al heel lang van de straat", grapt hij.

AI maakt de wedloop sneller

Ook kunstmatige intelligentie komt ter sprake. Koopmanschap noemt zichzelf "een fervent en zeer vocaal tegenstander van AI". Zijn belangrijkste bezwaren zijn ethisch van aard: hij wijst onder meer op energie- en watergebruik, grondstoffen en andere verborgen kosten. Tegelijkertijd ontkent hij niet dat de technologie krachtig is.

Koopmanschap noemt zichzelf "een fervent en zeer vocaal tegenstander van AI"Binnen softwarebeveiliging ziet hij een nieuwe wedloop ontstaan. AI kan worden ingezet om sneller zwakke plekken in code te zoeken. Dat biedt kansen voor beheerders van opensourcesoftware, maar dezelfde snelheid kan ook worden gebruikt om kwetsbaarheden uit te buiten. Daardoor wordt het volgens hem alleen maar belangrijker om systemen tijdig te patchen en niet vele versies achter te blijven.

Zelf probeert hij AI waar mogelijk te vermijden. "Ik zie echt wel de kracht van AI. Alleen heb ik heel veel problemen met de ethische bezwaren op dit moment." Hij ziet dus wat de techniek kan, maar vindt dat de maatschappelijke rekening te gemakkelijk buiten beeld blijft.

Creativiteit buiten de code

De platen van The Chemical Brothers en muziekapparatuur achter Koopmanschap verraden nog een andere kant van hem. Hij is vrijwilliger bij Concertzender en maakt zelf elektronische muziek, ooit begonnen met FastTracker 2 en inmiddels met een flinke verzameling hardware.

Zijn eigen werk beweegt tussen house, techno, intelligent dance music (IDM), ambient, noise en experiment. "Ik probeer niet te veel in één hokje te denken. Ik vind het leuk om allerlei verschillende dingen te doen." De overeenkomst met softwareontwikkeling is snel gevonden: beide vragen om technische kennis, nieuwsgierigheid en creativiteit. Soms is het nodig om de regels te kennen. Soms ontstaat juist iets interessants door ermee te spelen."Ik probeer niet te veel in één hokje te denken. Ik vind het leuk om allerlei verschillende dingen te doen."

Tijd voor muziek moet hij bewust reserveren. Soms blokkeert hij er simpelweg een hele dag voor. Dat lijkt verrassend veel op zijn advies over softwareonderhoud: wacht niet tot iets volledig vastloopt, maar maak er bewust tijd voor.

Een talk voor developers én beslissers

Met Lifecycle Management: de waarde van up-to-date software richt Koopmanschap zich nadrukkelijk niet alleen op developers. Ook techleads, managers en andere mensen die beslissen over tijd, budget en prioriteiten kunnen volgens hem veel aan de sessie hebben. Software duurzaam onderhouden lukt immers alleen wanneer de techniek en de organisatie dezelfde urgentie voelen. Hij laat zien welke risico's achterstallig onderhoud opleveren en hoe organisaties dure inhaalslagen voorkomen. Zijn boodschap: bedrijfskritische software vraagt blijvend onderhoud, liefst in kleine en beheersbare stappen.

Koop nu je kaartje voor de Tweakers Dev Summit 2026 en check het programma!

Ben je enthousiast geworden naar aanleiding van het verhaal van Stefan?
Koop dan hier een kaartje nu de tickets nog beschikbaar zijn. Meer informatie over het programma, workshops en sprekers vind je op de aparte Dev Summit-website. We zien je eind oktober!

Reacties (15)

Sorteer op:

Weergave:

Ik zie het wat in de trend van burgermeester/wethouder/minister opent nieuw gebouw/speeltuin/weg/brug enz enz, want nieuw en shiny, dus mooi in de krant/insta.

Maar ik zie ze niet in een nieuwsartikel als de weg nieuw asfalt heeft, de brug nieuwe bouten of de speeltuin gelakt is of een nieuw houten paneel heeft.


Onderhoud is zoooooo suf

[Reactie gewijzigd door Morress op 24 september 2026 08:29]

Of het nu nu software development, server en netwerk beheer, of inderdaad het onderhoud van de speeltuin gaat.

Onderhoud is altijd minder zichtbaar, tot het mis gaat (kijkt nu met een schuin oog naar Rijkswaterstaat en onze bruggen en gaat weer aan de slag met een in-place-server-upgrade).
En toch is ook dat een grappig voorbeeld. Want hoe vaak zie je niet dat een speeltuintje weer verwijderd moet worden omdat het niet meer aan veiligheidsvoorschriften voldoet door, jawel, een gebrek aan onderhoud. Dat gebeurt best vaak.
Klopt, specifiek speeltuinen is een vage bedoeling waar bovendien de speeltuintoestellenfabrikanten lobby héél veel invloed heeft op regels en controle daar op.

Bijvoorbeeld: ketting van tokkelbaan kapot. Lokale ijzerwaarhandel; 7,50. Maar er moet een officiele want reglement, zie daar 80euro, ex btw en levertijd én verzendkosten.


Het wordt nog raarder, de ene gemeente beheerd de speeltuin zelf bij andere gemeentes (alhier) is het beheer van de speeltuin onder een stichting waarbij het soms deel uit maakt van een buurtvereniging(alhier) of een speeltuinstichting. Zo komen we op de situatie waarbij we hier een stadje van 17k inwoners hebben met 17 stichtingen waar al dan niet nog een bestuur is die überhaupt bestaat en/of actief is.

Geen/amper geld in de stichting maar wel torenhoge eisen mbt onderhoud, een systeem waar de app voor registreren daarvan geen meter werkt en administratieve rompsplomp.

Nieuw speeltoestel?

Begint bij 25k voor iets redelijks.
Totdat bruggen en wegen 'instorten'. Ik herken wel wat je zegt. Ook managers willen soms 'shinen' naar hun baas. En dan is introductie van nieuwe features veel toffer dan uitfaseren (en daarmee vrijspelen van mensen/tijd/resources) van oude dingen. Kijk, als de sales/serviceafdeling nog steeds centen binnenkrijgt voor legacy spul en de kosten voor de legacy spullen in verhouding staan tot de inkomsten, dan is legacy in leven houden verdedigbaar.

Al heb ik te vaak gezien dat sales/service een compleet gescheiden wereld is van development en het in development erg lastig is te bepalen hoeveel legacy code nog kost. Zelfs als het onderhoud aan legacy code minimaal is, een nieuwe OS versie moet je vaak wel valideren (want de klant doet wel een upgrade van zijn hardware/OS, dat weer - soms - wel). Als development niet kan vertellen hoeveel procent van het development budget opgaat aan legacy code en daarmee potentieel meer geld opleverende nieuwe features (ook niet altijd waar, ook dat is lastig te meten, wat nu precies de doorslag gaf voor verkoop product of nieuw service/onderhoudscontract) dan worden er ook geen besluiten genomen.

Stop maar met onderhoud en dan maar eens kijken hoe lang het duurt voordat klanten ontevreden zijn. De materie is iig complex en de krachten binnen een bedrijf over geldstromen en verantwoordelijkheden vaak ook niet superduidelijk.

Zo tof is het ook niet als development zegt: die oude meuk, dat kost is x-fte per jaar. Wat levert het nu nog op? Kunnen we uitfaseren? Het risico dat de klant jouw bedrijf helemaal de rug toekeert (omdat een nieuwer product niet meer alles kan wat je oude product wel kon), is ook groot.

Leuk dat er aan dit 'l-woord' aandacht besteed wordt. Heel herkenbaar.

Overigens: waar vroeger een jaarlijkse release/update niet abnormaal was, is dat tegenwoordig veel korter. Op die manier kan de klant sneller (kleine) updates plaatsen, maar moet ook de developement, test, delivery etc procedures ook overweg kunnen met de veel hogere release frequentie. Dat vraagt soms (te) veel van organisaties (want escalaties komen ook nog tussendoor).
Onze offshore equiment wordt periodiek overhaalt , want op zee onderhoud is 1000x duurder.

Thuis dito met Synology servers en Plex, windows, android. Wekelijks onderhoud.
Home Assistant dito, ik snap dikke prima wat Stefan zegt. Het is Suf als een gemeente of overheid in de krant komt met achterstallig onderhoud, zo een brevet van onvermogen en het kost een vermogen achteraf.
Lubach had dat recent nog als onderwep: YouTube: Hoe kan het dat alle bruggen in een keer slecht zijn in Nederland? | LUBACH

Gaat ook over liever nieuwe dingen doen en onderhoud laten versloffen.
Inside joke voor een software architect die Koopmanschap heet zou ik juist verwachten dat ie SaaS predikt.

Inhoudelijk wel helemaal eens met het verhaal.
Mijn excuses dat ik niet aan de verwachtingen voldoe ;)

Ik ben helaas niet zo'n Koopmanschap als mijn naam doet vermoeden, ik ben groot voorstander van (heel gek) de juiste oplossing voor het juiste probleem. En soms is dat SaaS. En soms PaaS. En soms ouderwetse hardware. En soms Kubernetes (maar ook heel vaak niet). En soms maatwerk. En soms juist niet.
Ik ook hoor, maar snap wel dat veel organisaties waar it geen core business is SaaS tenzij policy hebben. Daarmee kun je altijd ook nog uitwijken naar niet SaaS als het niet past. Data soevereiniteit is tegenwoordig ook belangrijk argument.
Heel lang was SaaS de oplossing, en nu komen mensen erachter dat blind SaaS pakken juist vanwege die soevereiniteit niet de juiste manier was. Maar goed, dat is (deels) voortschrijdend inzicht ook. Pas als je fouten maakt weet je hoe het eigenlijk moet.
veel organisaties waar it geen core business is
Ik durf hier wel de stelling te poneren dat in de huidige wereld voor 99% van de bedrijven IT core business is, ook al denken veel bedrijven van niet. En dat is heel lastig uitleggen.
Deels eens. Het is essentieel voor hun core business maar niet hun core business. B.v. een kinderopvang organisatie gebruikt IT (want alles gaat digitaal) maar ze zijn geen ISP.

Ben het wel eens dat veel organisaties risico's en impact van IT (beschikbaarheid) onderschatten.
TL;DR:
Technical debt is ongewenst en kan je beter vermijden.

Door de versnelling van het ontdekken en misbruiken van 0-days, wordt de nadruk op gelaagde beveiliging steeds belangrijker. Je moet een beveiligingsmodel hebben waarbij het volledig wegvallen van een laag niet zorgt voor onacceptabele risico's.

Natuurlijk blijven updates belangrijk. Het klassieke "patchmomentje van de maand" is niet meer van deze tijd. Men zal steeds meer overgaan op automatisering voor testen, installeren en terugdraaien van updates.

[Reactie gewijzigd door The Zep Man op 24 september 2026 08:33]

Technical debt? Waarom zou je dat vermijden?

Al je de definitie volgt en goed leest hoe het bedoeld is, is er helemaal niets mis met technical debt. Zolang je net als bij financial debt je lening maar aflost. Als je er te lang mee wacht krijg je rente op rente, en wordt de koste om terug te betalen steeds groter.

Je zou het dus wijs moeten inzetten. Gebruiken wanneer een shortcut je versnelt in tijden van schaarste. goed registreren en later inlossen.

Om te kunnen reageren moet je ingelogd zijn