Door Jasper Bakker

Nieuwsredacteur

Windows-updates onder druk door tempo, complexiteit en minder kwaliteitscontrole

03-04-2026 • 10:00

53

Windows lijdt onder updates: door snelheid, complexiteit, QA-gebrek en AI?

Holt de kwaliteit van Windows-updates achteruit of lijkt dat maar zo omdat het vergrootglas erop ligt? Eind maart was er weer een probleem met een update voor het veelgebruikte besturingssysteem. Microsoft trok een update terug vanwege fouten. Dat gebeurde nadat in de afgelopen maanden andere updates ongewenste neveneffecten hadden. Het bedrijf belooft beterschap en kwaliteitsverbetering.

Het is makkelijk om te wijzen naar problematische updates voor Windows. Er zijn nu eenmaal veel updates voor dat Microsoft-platform en het is een groot, complex stuk software. Logisch dat er tussen de vele updates ook een bepaald aantal problematische updates zit. Windows is niet bepaald een minimalistisch besturingssysteem, draait op een enorm scala aan componenten, heeft flink wat legacy in zich voor compatibiliteit en wordt door heel veel mensen gebruikt. Op het Linux-gebaseerde Android na is Windows het meest gebruikte besturingssysteem ter wereld. In Europa is Windows wel groter dan Android.

Windows marktaandeel, maart 2026. Bron: Statcounter
Marktaandeel Windows, maart 2026. Bron: Statcounter

Spider-Man en kwaliteit

Android is, zoals alle software, ook niet bugvrij, maar brede updateproblemen zoals bij Windows lijken daar veel minder te spelen. Dat komt onder meer doordat smartphonemakers ruim de tijd krijgen om updates en nieuwe releases te checken en aan te passen voordat ze die uitbrengen voor hun hardware. Microsoft nam lang geleden de touwtjes voor updates zelf in handen. Distributie van updates verliep oorspronkelijk vooral via pc-makers, in de tijd vóór algemeen internetgebruik.

Met groot marktaandeel komt grote verantwoordelijkheid, om een bekende wijsheid uit de Spider-Man-verhalen te parafraseren. Windows Update moet als centraal punt van Microsoft het besturingssysteem voorzien van fixes voor bugs en kwetsbaarheden. Kwaliteit is daarbij het doel: kwaliteit van Windows door de uitgebrachte updates en kwaliteit van de updates zelf. Brakke drivers blijken de oorzaak van veel ellende. Dat was al zo ruim vóór het impopulaire Vista en ook bij het wel populaire Windows 10.

De afgelopen maanden – en zelfs jaren – lijkt er sprake van kwaliteitsverlies bij updates van Microsoft. De ingetrokken update van eind maart was weliswaar zelf nog een preview, maar gaf foutcodes bij het installeren. Het niet kunnen installeren van een update is fundamenteel. Eerdere Windows-updates die wel als 'rijp' waren uitgebracht, leverden gebruikers ook fundamentele problemen op.

BSOD Windows 11, Secure Kernel Error: bron: Bleeping Computer
BSOD op Windows 11. Bron: Bleeping Computer

Bricken, blokkeren en meer bugs

Zo brickte een update eind januari sommige pc's en blokkeerde een andere update Remote Desktop en de slaapstand voor enkele 'specifieke builds' van Windows. In november maakte een bug de wachtwoordoptie onzichtbaar op het lockscreen van Windows 11 voor sommige gebruikers. In diezelfde maand waren er berichten dat een verplichte securityupdate zorgde voor verstoring van Windows' zoekfunctie op netwerkschijven.

Ook in november veroorzaakte een cumulatieve update crashes van Windows 11, wat in december ook de recentere 25H2-release bleek te raken. De lijst met Windows-bugs door updates is lang, gevarieerd, soms bizar, soms frustrerend, niet op iedereen van toepassing maar ook wel onrustgevend. De updatesituatie is daardoor zorgwekkend te noemen.

Beterschap beloven

Vorige week beloofde Windows-topman Pavan Davuluri dan ook beterschap, in zijn eerste en tot nog toe enige blogpost voor Windows Insiders. Hij gebruikte formuleringen als 'strengere validatie', 'stevigere betrouwbaarheid' en 'betere feedbackloops'. Dat laatste moet ervoor zorgen dat Microsoft problemen sneller opmerkt, prioriteit geeft en oppakt.

Davuluri spreekt niet ronduit van achteruitgang in de kwaliteit van Windows en biedt ook geen excuses aan, merkt The Register kritisch op. De Microsoft-topman houdt wel herhaaldelijk kwaliteitsverbetering voor en dat in relatie tot feedback van Windows Insiders. Het belang van die externe testers is groot en in de afgelopen jaren ook veel groter geworden.

Windows 11 Insider Preview builds. Bron: Microsoft
Windows 11 Insider Preview Builds. Bron: Microsoft

Van waterval naar agile

Daar zijn twee oorzaken voor, die weer gelinkt zijn aan de kwaliteit van updates voor Windows. De ene oorzaak is het feit dat de ontwikkeling van het besturingssysteem meer en meer berust op agileprincipes, in plaats van op de ouderwetse watervalmethode. Agile betekent in korte ontwikkelsprints functionaliteit maar ook fixes opleveren, die snel uitbrengen en er op voortbouwen in volgende sprints. Of ze bij eventuele problemen dus fixen.

Voorkomen is beter dan fixen, maar dat kan er bij snel ontwikkelen bij inschieten. Bovendien heeft een organisatie dan wel een gedegen kwaliteitsafdeling nodig. Microsoft was in de jaren negentig vooruitstrevend bezig met de expliciete rol van een software-ingenieur die niet bezig is met het produceren van productcode, maar met het maken van testprocedures daarvoor.

De rol van de software development engineer in test (sdet) gaat veel verder dan een afdeling kwaliteitszorg die geproduceerde software uitprobeert en de ontwikkelaars dan feedback geeft. De combinatie van testingenieur, softwareontwikkelaars en traditionele testers kan de kwaliteit van geschreven code verhogen. In de praktijk wist Microsoft dit niet altijd waar te maken: uitstel en bugs plaagden grote softwarereleases.

In de loop der tijd evolueerde de sdet-rol om de productiviteit van ontwikkelaars te verhogen, bijvoorbeeld door ze betere tools te geven. In 2014 voerde Microsoft flinke veranderingen door. De gehanteerde ontwikkelpraktijken werden de eenentwintigste eeuw ingesleurd, schreef Ars Technica toen. Van watervalmethode naar agile aanpak.

Ontwikkelaar, code, ontwikkelen, software, lowcode. Bron: Microsoft
Ontwikkelaar aan het werk. Bron: Microsoft

Reorganiseren en meer automatiseren

De andere oorzaak voor het veel grotere belang van externe testers is dat Microsoft daar zelf op bespaart. Het sneed flink in zijn personeelsbestand: duizenden werknemers werden in 2014 ontslagen. Dit raakte ook interne testers. Een 'flink deel' van de Windows-ingenieurs die testwerk deden, was volgens bronnen van ZDnet 'niet langer nodig'.

In plaats daarvan zouden programmamanagers en software-ingenieurs de kwaliteitscontrole op ontwikkelde code op zich nemen. Volgens voormalig Microsoft-ingenieur Gergely Orosz was dit het einde van de sdet-rol. Volgens bronnen van Bloomberg sneed Microsoft-ceo Satya Nadella in de QA-afdeling van het bedrijf. Tests en controles werden meer uitgevoerd door softwareschrijvende werknemers zelf, ondersteund door geautomatiseerde systemen.

Dit maakte het mogelijk om Windows 10 regelmatig te voorzien van updates. Waar het voorheen jaren kon duren voordat nieuwe functionaliteit – vaak in de vorm van een nieuwe Windows-versie – uitkwam, verschenen er halfjaarlijkse nieuwe releases. Naast de maandelijkse updaterondes die patches brengen voor bugs en kwetsbaarheden.

Saas-trend volgen

Microsoft noemde dit Windows-as-a-service (Waas), verwijzend naar het releasemodel van cloudbedrijven die software als onlinedienst ontwikkelen, bijwerken en aanbieden. Het softwarebedrijf rekende hierbij ook op testwerk van externe experts: de Windows Insiders die vroege softwareversies uitproberen. In theorie was dit een moderne, soepele opstelling die snelheid combineert met kwaliteit.

In de praktijk kwam er na verloop van tijd de klad in. Uitgebrachte updates gaven onverwachte en soms ernstige problemen, die Microsoft met aangepaste updates weer moest oplossen. In sommige gevallen waren de problemen in een vroeg stadium al opgemerkt door Windows Insiders in previewreleases.

Windows 11, laptop op tafel, startmenu. Bron: Microsoft
Windows 11-laptop. Bron: Microsoft

Microsoft schroefde het ontwikkeltempo voor Windows wat terug. In plaats van elke zes maanden een grote nieuwe release kreeg Windows elke lente een bescheiden update en elke herfst een functioneel grotere update, naast de maandelijkse updaterondes. Voor Windows 11, dat eind 2021 uitkwam, ging het tempo officieel omlaag. Voortaan kreeg het besturingssysteem een grote release per jaar: in de herfst.

Begin 2022 kondigde Microsoft echter aan dat het een nieuwe ontwikkeltrend toepaste. Verbeteringen zouden doorlopend uitkomen, wat 'continue innovatie' moest brengen. Naast de grote jaarlijkse updates en de maandelijkse updates zouden er dus vaker kleinere updates komen.

AI-code versus olietanker?

Bovenop deze ontwikkelingen komt de relatief nieuwe trend van AI en AI-gegenereerde code. Een trend die de Windows-maker zelf ook volgt. Twintig tot dertig procent van alle code in de repository's van Microsoft was in mei vorig jaar door AI gegenereerd. Microsoft-ceo Satya Nadella zei dat sommige projecten 'waarschijnlijk zelfs al helemaal door software' waren geschreven. Hij noemde geen concrete voorbeelden en het is dus onzeker of dit geldt voor Windows, of voor updates voor dat Microsoft-product.

Wel is het duidelijk dat Microsoft doorgaat met AI-gebruik voor zijn eigen softwareproductie. In juli vorig jaar voerde het bedrijf een forse ontslagronde door. Een groot deel van de 9000 ontslagen vielen bij de gamingafdeling, maar het raakte ook de centrale kwaliteitszorg voor gamesontwikkeling. Sommige van de geschrapte functies bij Microsoft worden ingevuld door AI-tools.

Microsoft-ceo Satya Nadella, AI, Amsterdam. Bron: Microsoft
Microsoft-ceo Satya Nadella. Bron: Microsoft

Mogelijk dat Microsoft door AI geschreven code benut voor minder kritieke software en niet of nauwelijks voor Windows. Ook is het mogelijk dat de gevolgen van veranderingen in de ontwikkelaanpak en besparingen op testgebied van jaren terug nu pas naar buiten komen. Grote softwareprojecten zijn te zien als logge olietankers, waarbij koerswijzigingen niet snel kunnen. Bijsturen kost dan ook weer tijd.

Onder hoge druk

Ondertussen staat Windows, net als andere veelgebruikte software, onder toenemende druk van aanvallers die kwetsbaarheden vaker en sneller misbruiken. Het maken, testen en uitbrengen van securityupdates is meer en meer een wedloop. Daarbij is kwaliteit cruciaal, zowel voor de beveiligingspatches als voor Windows zelf.

Deze belangrijke updates staan naast de jaarlijkse grote releases, de maandelijkse bugfixes, de out-of-bandpatches voor kritieke problemen en de continue functionele verfijningen voor Windows. Bovendien is het pc-besturingssysteem lang niet het enige product van Microsoft waar het prioriteit aan moet geven. Clouddiensten leveren het bedrijf flinke inkomsten op. De brede integratie van AI in uiteenlopende producten, inclusief Windows, kost het bedrijf flinke ontwikkelinspanning. Dat heeft weer impact op Windows en updates daarvoor.

Redactie: Jasper Bakker • Eindredactie: Monique van den Boomen

Microsoft, ontwikkeltools, Windows, GitHub, tools. Bron: Microsoft
Ontwikkeltools, Windows, GitHub. Bron: Microsoft

Reacties (53)

Sorteer op:

Weergave:

Als ik het hoofdstuk "Van waterval naar agile" zo lees dan is het beeld van wat Agile is een veel groter probleem dan Agile zelf.
Voorkomen is beter dan fixen, maar dat kan er bij snel ontwikkelen bij inschieten.
Nee, dat kan er bij écht agile software ontwikkeling helemaal niet bij inschieten aangezien dit inherent onderdeel is van het werk. Maar:
Bovendien heeft een organisatie dan wel een gedegen kwaliteitsafdeling nodig.
Als je dit schrijft heb je echt niets begrepen van agile software ontwikkeling. Een "gedegen kwaliteitsafdeling" is de doodsteek van kwaliteit in een agile omgeving. Kwaliteit is de verantwoordelijkheid van hetzelfde team wat de functionaliteit realiseert en niemand anders. Juist het uitbesteden van kwaliteit geeft de zekerheid dat de kwaliteit achteruit zal gaan.

Hiermee maakt het stuk duidelijk dat daadwerkelijke agile software ontwikkeling zelfs bij Tweakers onbekend is. En als we het hier al niet snappen, hoe kunnen we dan verwachten dat grote bedrijven het begrijpen?

Agile is hier niet het probleem. De verandering van Waterval naar Agile is ook niet het probleem. Het probleem is dat grote bedrijven (en blijkbaar ook de Tweakers redactie) geen flauw idee hebben hoe software ontwikkeling in elkaar steekt. Het maakt op dat moment dus ook helemaal niet meer uit of je je proces Waterval, Agile, Scrum, Kanban, DSDM, Smurf of Japie noemt.

[Reactie gewijzigd door Croga op 3 april 2026 11:02]

Agile is hier niet het probleem.
Als het overschakelen naar agile zorgt dat kwaliteit achteruit gaat omdat niemand agile begrijpt, dan is (het overschakelen naar) agile het probleem. Immers begrijpt niemand het.

[Reactie gewijzigd door The Zep Man op 3 april 2026 10:52]

De basisprincipes van Agile zijn zo simpel, dat begrijp iedereen.

Nee, Agile is niet het probleem, maar de mensen die Agile bij sommige organisaties (onterecht) de strot door duwen. Agile is geen magische oplossing voor ieder bedrijf. Het is oorspronkelijk bedacht voor software-ontwikkeling en daar is het, op wat edge-cases na, bijna onmisbaar geworden. De werkwijze past per definitie echt niet in iedere branche.

Daarnaast is je 100% aan alles vast houden wat Agile voorschrijft óók niet de bedoeling. Je neemt de basis van Agile (iteratief ontwikkelen) en kijkt welke andere zaken positief kunnen bijdragen aan het werkproces van jouw bedrijf/team/afdeling op het gebied van efficiëntie, kwaliteit etc.
De basisprincipes van Agile zijn zo simpel, dat begrijp iedereen.
@Croga schrijft:
Als je dit schrijft heb je echt niets begrepen van agile software ontwikkeling.
Jullie hebben stellingen die lijnrecht tegenover elkaar staan. Gezien ik vaak genoeg geconfronteerd wordt met de intelligentie en het begrip van het deel van de populatie dat hiervoor onder het gemiddelde valt, ben ik geneigd om niet jouw stelling te geloven.
Nee, Agile is niet het probleem, maar de mensen die Agile bij sommige organisaties (onterecht) de strot door duwen.
Waarom is het onterecht dat men agile door de strot duwt? Of beter: waardoor duwt men (onterecht) agile door de strot?
Agile is geen magische oplossing voor ieder bedrijf.
Dus het kan in bepaalde situaties problematischer zijn dan zaken die het (beoogd) op te lossen. Dat is dus een probleem.
Daarnaast is je 100% aan alles vast houden wat Agile voorschrijft óók niet de bedoeling. Je neemt de basis van Agile (iteratief ontwikkelen) en kijkt welke andere zaken positief kunnen bijdragen aan het werkproces van jouw bedrijf/team/afdeling op het gebied van efficiëntie, kwaliteit etc.
Dat is gewoon de PDCA-cyclus onder een fancy naam. :+
Dat is gewoon de PDCA-cyclus onder een fancy naam. :+
Agile is ook niet echt bijzonder; het is heel veel dingen die we al jaren, zo niet eeuwen, weten maar dan met een fancy naam
Ik denk dat we hier een beetje langs elkaar heen praten. Ik zal zo goed mogelijk proberen te reageren. Overigens heb ik zelf ook slechte ervaringen gezien met hoe Agile in de praktijk (foutief) wordt toegepast.
Jullie hebben stellingen die lijnrecht tegenover elkaar staan. Gezien ik vaak genoeg geconfronteerd wordt met de intelligentie en het begrip van het deel van de populatie dat hiervoor onder het gemiddelde valt, ben ik geneigd om niet jouw stelling te geloven.
De 4 waarden van Agile (zoals in het Agile Manifesto) zijn vrij simpel en voor iedereen te begrijpen. Het gaat pas mis als er allerlei tools of rituelen (stand-ups, retrospectives) worden gebruikt, terwijl dat totaal onnodig is in de context waarin gewerkt wordt.
Waarom is het onterecht dat men agile door de strot duwt? Of beter: waardoor duwt men (onterecht) agile door de strot?
Agile is ontstaan in softwareontwikkeling. In andere domeinen kan het werken, maar vaak zie je dat het klakkeloos wordt overgenomen zonder de juiste context, waardoor het slecht uitpakt. Agile was een paar jaar geleden een buzz-word en iedere manager wilde er iets mee doen want het was een magische oplossing voor hun probleem. Terwijl hun business niets met software-development of uberhaubt IT te maken had.
Dus het kan in bepaalde situaties problematischer zijn dan zaken die het (beoogd) op te lossen. Dat is dus een probleem.
Dat klopt, maar dat geldt voor elke (werk-)methode: de effectiviteit hangt sterk af van de context waarin je hem toepast.
Dat is gewoon de PDCA-cyclus onder een fancy naam.
Mijn uitleg is misschien wat gechargeerd, maar PDCA en Agile zijn niet hetzelfde en focussen zich op andere dingen.

De PDCA-cyclus is een generieke verbetercyclus: je gebruikt hem om een proces of werkwijze te analyseren en stap voor stap te verbeteren.

Agile is een manier van werken gericht op het iteratief opleveren van concrete resultaten (bijv. een applicatie), met continue feedback van stakeholders. Daarbij verbeter je niet alleen het proces, maar lever je ook tussentijds waarde op.

Je kunt PDCA prima binnen Agile toepassen (bijvoorbeeld via retrospectives), maar Agile is breder: het gaat niet alleen over verbeteren, maar ook over hoe je werk organiseert, samenwerkt en waarde levert.
Hoe vaak ik al heb gehoord "We gaan als IT Ops Agile werken!" bij verschillende opdrachten (lang leve detachering!) en als je dan vraagt: Hoe dan? Komen ze met ideeen waarbij je dus alleen het verbeter gedeelte van OPS agile zou kunnen gaan doen, maar ze vergeten dat de incidenten, changes en projecten voor de business zoveel tijd opslokken dat die verbetertrajecten eigenlijk altijd ondersneeuwen, waardoor ook agile dat probleem niet gaat oplossen.
Het probleem is vooral dat niemand de tijd neemt Agile te begrijpen. Bij veel bedrijven wordt er een scrum cursus gevolgd en noemen ze zichzelf Agile terwijl zo nog nooit van het Agile manifesto hebben gehoord. En eigenlijk, agile is niets meer en niets minder dan dat manifesto, het is geen framework, geen tool, geen handleiding. Het is een idee met een aantal principes, niets meer en niets minder. En 1 ding durf ik wel te zeggen, dat volgt Microsoft niet en hebben ze ook nooit gedaan (net zoals de grote meerheid van bedrijven die zeggen "Agile" te zijn).
Ja en iedereen wilt eraan sleutelen waardoor het vlees noch vis wordt.

Fundamenteel is het denk ik, los van het Agile-verhaal, wat moeilijk juist te implementeren is, wel grotendeels gewoon een agressief in de kosten snijden om tijdelijk de beurswaarde op te krikken (wat gelukt is).
Eens. De overstap op Agile leverde m.i. juist veel meer winst op. Bij de waterval methode waren horden managers aan het vergaderen wat er nu net wel of niet niet in de scope pastte. Dat ben je met Agile kwijt, omdat het adagium meer is: als iets (kleins) af is, gaat het mee, is het niet af, dan de volgende ronde. Gevolg is dat je minder - op papier - op tijd kunt sturen, maar wel een hoop overhead (vergaderingen) kwijt raakte.

Verder is wel of niet testen, aparte of geintegreerd in het development team iets wat los staat van Agile of waterfall methode IMO. Beide taken zijn namelijk via beide methodieken in te plannen.

Wat wel helpt: als ontwikkelaars hun eigen software moeten onderhouden, zal shit-code ook een rij bugs opleveren, die ze vervolgens mogen fixen. Fixen is minder leuk dan nieuwe features maken. Dus maak je features gelijk maar goed (fouten worden er altijd nog wel gemaakt). Voordeel van Agile is dan wel weer dat kleine taken ook beter van (unit) tests te voorzien zijn. Bonus voor de kwaliteit (meestal).

Maar uiteindelijk is testen tijdens ontwikkeling een mindset. Zowel het dev-team als de managers moeten er achterstaan.

Ik mis in het artikel een beetje de onderbouwing van 'wat is nu slechter' geworden. Gaat het nu echt vaker mis. Oude-knarren zullen zeker wel herinneren dat BSOD's veel en veel vaker voorkwamen (oorzaak vaak hardware, niet perse Microsoft code). Het gaat volgens mij ook erg vaak goed. Daarbij is het aantal PC's/laptops nu, waarschijnlijk ook een stuk groter dan - zeg 10-20 jaar geleden. En als de wereld om je heen steeds vaker/eerder gebruik maken van exploits: er is geen oneindige rek in ook zelf nieuwe updates ook weer sneller uit te brengen. Die tendens van 'steeds sneller' is overal zichtbaar. Vroeger 1x per 3 maanden een release (of nog veel minder vaak), tegenwoordig soms 1x per week. Dat vraagt - ondanks grote mate van automatisering - ook e.e.a. van een organisatie, die naast releasen ook het 'normale' werk heeft. De hijgeriheid is een mix van de haast van een klant/gebruiker en de komst van hacker tools, die door Sjors of Sjimmie gebruikt kan worden (en grote schade aan kan richten, ondanks het gebrekkige kennisniveau van de aanvaller). Uiteraard zijn er ook aanvallers met (zeer veel) kennis van zaken. Kwaadaardigheid heeft ook altijd al bestaan.

PS. @Croga je formatting van de quotes zit niet helemaal goed
Verder is wel of niet testen, aparte of geintegreerd in het development team iets wat los staat van Agile of waterfall methode IMO. Beide taken zijn namelijk via beide methodieken in te plannen.
Da's nog wel een lastige;
In principe is testen in het team een onderdeel van goede software engineering methoden en daarom los van methodiek. Echter is daar nog wel wat aan af te dingen;
Waterval schrijft expliciet een test periode voor. Daarmee is het weliswaar niet persé een ander team maar zeker een andere fase.
XP schrijft expliciet TDD voor. Daarmee is het (in combinatie met de rest van XP) inherent onderdeel van hetzelfde team geworden.
Daarnaast schrijft Scrum, bijvoorbeeld, voor dat alles wat nodig is voor een product in productie onderdeel is van het team. Daarmee dus ook impliciet aangevend dat testen door hetzelfde team wordt gedaan als het schrijven van code.
In de basis heb je gelijk en is kwaliteit inbouwen door het team zelf niet persé afhankelijk van methodiek maar methodiek heeft er wel degelijk een hele grote invloed op.
Exact dit. Welke methode je ook gebruikt: als de basis niet op orde is dan gaat het uiteindelijk mis. Elke methode heeft immers voor- en nadelen. Ik ben altijd heel kritisch op Agile, want het is echt geen 'middel tegen elke kwaal' zoals sommige Agile evangelisten beweren, maar kijk vooral ook verder als er structurele problemen optreden.
Nee, dat kan er bij écht agile software ontwikkeling helemaal niet bij inschieten aangezien dit inherent onderdeel is van het werk.
Je beseft dat voor een product als Windows je door alle variaties weken aan een final build (geatomatiseerd) aan het testen bent? Dan werkt agile met een maandelijkse release-cycle eigenlijk niet meer.
Het probleem is dat grote bedrijven (en blijkbaar ook de Tweakers redactie) geen flauw idee hebben hoe software ontwikkeling in elkaar steekt. Het maakt op dat moment dus ook helemaal niet meer uit of je je proces Waterval, Agile, Scrum, Kanban, DSDM, Smurf of Japie noemt.
Ik heb een paar jaar heel diep in de keuken van Microsoft US bij de productteams mogen kijken. Ik werkte toen bij het Software Engineering Research Centre van de Uni Utrecht. Ik heb een hoop geleerd van ze...
Hoewel testen net zo goed bij Agile hoort, betekent de meer iteratieve aanpak vaak dat er op kleine delen wordt gefocust en daarbij wil het grotere plaatje nogal eens verdwijnen, dit kan ook (eerder) bugs geven.

Daarnaast wordt de input van Agile vaal aangestuurd door wensen en bugs, maar onderaan de streep blijft dan onderhoud aan andere componenten vaak liggen, op termijn kan er dan technical debt daaraan ontstaan.

Het hangt inderdaad in sterke mate van de organisatie af hoe hier mee wordt omgegaan maar mijn ervaring is wel dat Agile gevoeliger is voor procesfouten dan watervallen, los van het een betere methodiek is.
En toch.. grote bedrijven hebben meerdere managementlagen, degene die bepaalt welke methodiek gebruikt wordt en hoe deze geimplementeerd wordt heeft er vaak geen kaas van gegeten en doet wat copilot vindt dat goed is (laten we wel wezen)

De hierarchie is vaak zo strak dat de mensen met verstand van zaken niks in te brengen hebben en zelfs gestraft worden als ze een mening uiten. Tel daarbij op dat men dit soort dingen uitbesteed aan lage lonen landen waar men helemaal geen tegendruk geeft (o.a. India) en je hebt het ideale recept voor een logge softwarepijplijn met een perfect compliant proces waar ontzettend veel troep doorheen komt.

Wat dit extra saillant maakt is dat de devops learn track van Microsoft het wel goed doet, maar dat is in een theoretisch bedrijf met een klein team :+
Dat uitbesteden aan lage lonen landen en geen tegendruk geven heeft ook nog een ander probleem.
De mensen daar doen gewoon letterlijk wat je vraagt, zonder even verder na te denken, want ze weten niet wat de achterliggende gedachte van de usecase is, of wat het nu echt voor probleem moet oplossen.

Iemand die binnen de organisatie zit, zal sneller geneigd zijn om even verder na te denken, contact op te nemen en de kern van de usecase uit te pluizen om zo direct tot de gepaste oplossing te komen, in plaats van dat er 4 fixes overheen moeten in de volgende sprints.
Agaile ontwikkelen is zowel een voordeel als een nadeel. Je ontwikkeld sneller een "werkend" product waar je feedback op krijgt. MAAR! Dit zorgt er ook voor dat je pas veel later een voltooid product krijgt en dat tussenreleases vervelende nadelen hebben.
Dit zie ik eigenlijk overal waar grote projecten "agile" ontwikkeld worden. Ik denk dat er dan wel een andere ontwikkelmethode gebruikt zou moeten worden. (niet waterval, maar iets wat betere testen bevorderd)
Dit heeft werkelijk helemaal niets met agile ontwikkelen te maken.

Als een bedrijf/project/team niet snapt hoe goede software ontwikkeling werkt gaat de methode daar niets aan veranderen. Als ze het wel snappen dan vormt zich vanzelf een juist proces wat veel weg heeft van agile. "Beter testen" is onderdeel van de manier waarop een team naar software engineering kijkt. Binnen Agile zou dat inherent onderdeel moeten zijn van het proces. En again; als men dat niet begrijpt dan is het product zowieso gedoemt om een kwaliteist probleem te hebben, of het nu waterval, agile, scrum of jan-boeren-fluitjes heet.
Waarom is er zo'n groot verschil tussen Windows en MacOS? Ik hoef zelden updates te installeren, het werkt altijd. Soms een hotfix voor een gebruikte exploit, maar verder alleen grote updates om de zoveel maanden. Ik merk het ook aan Office op een Mac. Er gaan weken voorbij waar er meerdere dagen een update is :?
Bor Coördinator Frontpage Admins / FP Powermod @skaars3 april 2026 10:50
Er is niet zo'n groot verschil. Ook bij MacOS gaan er dingen fout en breekt een update wel eens wat (of fixed het iets niet geheel). Dat heb je helaas bij elk OS.
Omdat mac-os veel minder gebruikt wordt en dus minder interessant voor hackers om vulnerabilities te ontdekken. Als mac-os het marktaandeel had gehad van wat Windows nu heeft, had je ook veel meer updates gehad.
WaaS in plaats van OSaaS, want dat bekt natuurlijk lekkerder, en straalt het ego wat meer.

Ik heb genoeg gedoe met mijn MacOS, ik ben helemaal klaar voor de uprising van stabiele Linux distro's voor desktop & gaming gebruik. Voor servers is het fantastisch, voor persoonlijk nog net niet.
Never nooit problemen gehad met een update. Alles werkt als een zonnetje :)
Graapig deze morgen nog een device gehad, die na update niet meer wilde booten.
Voor mij is Windows een noodzakelijk kwaad door de wens om zorgeloos en met zo veel mogelijk performance te gamen zo nu en dan. Mijn ervaring met de desktop omgeving is best goed maar het is wel jammer dat Windows beteugeld moet worden met tools zoals W10Privacy en Win11Debloat -- en dan blijft het soms alsnog sappelen. Ik moet zeggen dat ik met Windows Updates nooit echt pech heb gehad, in tegenstelling tot sommige Linux-kernels die kwamen met bugs in basale ACPI-functionaliteit, om een dwarsstraat te noemen. Neemt niet weg dat de problemen bij QC door/van Microsoft echt zijn, en ook geadresseerd moeten worden. Het is in ieder geval fijn dat Microsoft dit zelf publiek onderschrijft en het zou ook de "maar ik heb nooit ergens last van"-opmerkingen wat moeten indammen zou je denken.
In deze tijd moet je echt eens goed kijken of Linux niet beter alternatief is dan Windows. Op veel van onze zakelijke PC's doen we niets anders dan inloggen op een remote applicatie (ERP, WMS, CRM). Je kan een immutable distro pakken met read only bestandsysteem. Scheelt je bedrijf ook wat in kosten (kan op oude laptops en geen OS license nodig) en het is nog stabieler ook, zo blijkt de laatste tijd. Zelfs de Cloudflare bug zou je dan bespaard zijn gebleven.
en je had vast weer andere bugs voor terug gekregen.

Een read-only OS kan je ook maken met Windows, kijk maar naar Windows IoT.

https://learn.microsoft.com/en-us/windows/configuration/unified-write-filter/

En die Cloudfare bug had net zo goed kunnen optreden bij Linux. Of wil jij stellen dat het onmogelijk is om Linux unbootable te maken?
Het punt is niet dat Linux geen bugs heeft of dat het onmogelijk is om een Linux-systeem onbruikbaar te maken. Het verschil zit in de architectuur en de beheerstrategie.

Bij een immutable Linux-distro wordt het basissysteem niet continu aangepast. Updates worden als geheel uitgerold en je kunt direct terugrollen naar een vorige werkende versie. Dat verkleint de kans dat één foutieve update massaal systemen onbruikbaar maakt én maakt herstel eenvoudiger.

Windows IoT kan inderdaad ook een read-only-achtig model bieden. Alleen is dat in de praktijk een niche-oplossing met veel beheervereisten. Bij veel moderne Linux-distro’s is immutability juist het uitgangspunt.

Wat betreft de Cloudflare-bug: natuurlijk had een soortgelijke fout ook in Linux kunnen zitten. Het argument is niet dat Linux immuun is, maar dat een minimalistische, immutable client die alleen dient als thin client voor remote ERP/WMS/CRM malafide aanvallen en updatecomplexiteit sterk beperkt. Minder componenten, minder updates, minder services, minder bewegende delen.

Daarbij komt dat voor werkplekken die uitsluitend een browser of RDP-client nodig hebben: geen Windows-licenties nodig zijn. En oude hardware langer bruikbaar blijft.

Het gaat dus om risico-reductie en kostenoptimalisatie in een specifieke use case. Niet om het idee dat Linux bugvrij is.
nou, voor alleen browser toegang of RDP toegang heb je thinclients en zeroclients tot je beschikking :)
Of eventueel een vmware horizon of andere VDI omgeving. Kan je prima gestandaardiseerd uitrollen.

Bedenk alleen wel dat als je zakelijk Linux gaat inzetten, je daarvoor ook een supportafdeling nodig hebt, gebruikers opleiden, een heel management omgeving nodig hebt voor user account control, software uitrol en patching, hardware/software monitoring, policies, remote beheer, etc, etc. Het is allemaal mogelijk met Linux, alleen is Windows de standaard hiervoor in de zakelijke wereld. Ik zeg niet dat het niet kan, ik zou het leuk vinden om daar ook mee te werken. Maar er komt veel meer kijken bij het gebruik van Linux in een zakelijke omgeving dan sommigen denken. Het is meer dan een endpoint plaatsen en klaar.
Daarom blijf ik voorlopig mooi op Windows 10 ESU hangen, zelfde gedaan destijds met Windows 7, zodra Windows 10 geen nieuwe features meer ontving was het wel een stuk stabieler te noemen dan de voorgaande jaren na de technical preview, nu wacht ik mooi totdat Windows 11 in maintenance mode gaat dan zijn er geen ingrijpende veranderingen die telkens de zooi stuk maken.
Mijn ongezouten mening: ze stoppen steeds meer ongevraagde rommel in Windows (oa Notepad, Copilot) en ze gebruiken zelf steeds meer AI om code te schrijven en bezuinigen daarmee op goede mensen. Dat is vragen om meer bugs en slechtere fixes.
Helemaal eens. Terwijl MS zelf in z'n Copilot Terms of Use waarschuwt dat Copilot niets meer dan een spelletje is, geen serieus hulpmiddel: Copilot is for entertainment purposes only. It can make mistakes, and it may not work as intended. Don’t rely on Copilot for important advice. Use Copilot at your own risk.
Heb je al eens Linux geprobeerd? Linux Mint lijkt best sterk op Windows en werkt eigenlijk voor veel use cases beter dan W11. Geen bloatware, geen telemetrie, geen verplichte Microsoft account. Heerlijk.
Een preview update terugtrekken vind ik niet zo erg. Daar werd echt van een mug een olifant gemaakt.

Verder goed stuk.

Heb zelf weinig problemen, met name omdat mijn Windows helemaal gestript is dmv. autounattend, scripts en groepsbeheer poilicies.

Om te kunnen reageren moet je ingelogd zijn