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

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.

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 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

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 agile principes, 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 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. 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. 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}

Ontwikkeltools, Windows, GitHub. Bron: Microsoft

Reacties (123)

[Croga]

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]

[The Zep Man]

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]

[Sito]

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.

[The Zep Man]

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.

[Sito]

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.

[jorisporis]

Vaak wordt agile gebruikt om een probleem op te lossen dat het niet kan oplossen. Micromanagement, teveel projecten tegelijk aanpakken, besparingen, gigantische veel ongerichte communicatie of net helemaal geen communicatie. Dan zal je met agile dezelfde problemen behouden als een watervalproject. Veel van die dingen zijn ook gewoon in strijd met de agile principes dus dan word agile een hol begrip.

[Vayra]

Exact.

Daarom moet Agile van boven tot onder in de organisatie begrepen en gedragen worden. Men haalt vaak in de reclamepraatjes Spotify aan. Ik geef dan altijd terug dat bij Spotify het management ook begreep dat het einddoel blijft staan, maar hoe de teams er komen volledig aan de teams werd gelaten. Dat betekent dus dat je als manager eigenlijk geen fuck meer te doen hebt - om niet te zeggen volledig overbodig wordt.

Bleek vaak een eye opener en leidde tot afkeurende vibes En dan weet je dat Agile gewoon als management middel wordt ingezet om meer taken aan de onderkant neer te leggen terwijl die ruimte er eigenlijk vaak niet is.

[Reactie gewijzigd door Vayra op 4 april 2026 19:30]

[Croga]

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}

[walteij]

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.

[satya]

Is ook een vak apart want het vraagt heel wat kennis van de omgeving en de software om het te kunnen doen, kennis en kunde die vaak niet bij operations aanwezig is.

[walteij]

Ops, de club die letterlijk de IT infra installeert, update, lifecycled en verder onderhoud. Kennis van de omgeving is wel aanwezig over het algemeen. Maar hoe wil je agile gaan werken in een afdeling die 50% van de tijd pro-actief onderhoud doet, 30% van de tijd voor projecten en changes bezig is, 10-15% van de tijd kwijt is aan incidenten en dan in die laatste 5% probeert aan verbetering te doen.
Ik zie niet hoe je een dergelijke omgeving met agile gaat beheren en onderhouden. Tenzij je allerlei repeterende taken in je backlog hebt staan die je dan in een specifieke sprint wil afhandelen. Maar daar zijn betere oplossingen voor dan een kanban bordje en een agile methodiek.

[satya]

Daar komt imho SRE en goede observability om de hoek kijken. Vaak werkt het wel (kwantiteit) maar weten we niet hoe goed (kwaliteit).

Ik ben redelijk gecharmeerd van Coroot. Eenvoudig uit te rollen, brengt heel het applicatie landschap automatisch in beeld en kijkt naar logs en metrics met standaard waarden. Alles wat afwijkt komt in beeld (logs en (database/java)metrics etc) en kan indien gewenst handmatig of automatisch met Ai onderzocht worden.

Dan kunnen de bottlenecks in kaart worden gebracht en kan er gestuurd worden op kwaliteit.

[Vayra]

Klopt allemaal wat je zegt, maar juist die losvaste 'we doen wel wat Agile waar het kan' is de nagel aan de doodskist van kwaliteit. Op het moment dat je niet echt kiest, kies je voor niets en krijgt je stagnatie. Niet kiezen is dodelijk (en niet 'ook een keuze' zoals dan soms wordt gezegd...). En ja, een keuze gaat uiteindelijk over principes en visie. Je wil een doel bereiken en je vindt dat je daar op een bepaalde manier het beste komt. Ga dat dan ook doen.

Ik zie het dagelijks om me heen. Watervalplanningen icm agile werkwijze. Lets go. En vervolgens gaan we in talloze events elkaar bevragen waarom het toch niet zo lekker werkt en ondertussen bouw je bergen aan waste en demotivatie op. Als je kiest voor Agile en kortcyclisch werken dan moet je je projecten en business plannen ook zo opstellen. Als de organisatie niet top to bottom Agile wil denken en doen, dan ga je vooral heel veel problemen veroorzaken met Agile. Houd dan maar gewoon vast aan een strak projectplan met watervalplanning en red wat er te redden valt onderweg.

Ik noem Agile ook wel eens gekscherend 'Fail Forward'
Ook wel te vertalen als 'voortschrijdend inzicht' om het een positieve draai te geven. Maar dat is het echt, en dat moet je in de organisatie ook uitdragen. Je weet niet alles vantevoren, pretendeer dat ook niet, en neem kleine stapjes, en vertel ook het management dat dat de weg is. In de huidige dynamiek/wereld/economie past Agile ook ontzettend goed. De wereld kan er morgen echt compleet anders uitzien.

[Reactie gewijzigd door Vayra op 4 april 2026 19:21]

[DdeM]

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).

[NoTechSupport]

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).

[pixeled]

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

In mijn optiek is dit veel te kort door de bocht. Als je de haakjes om "het overschakelen naar" hier weghaalt dan kan ik het met je eens zijn; de transitie naar agile kan zeker een probleem zijn als die niet goed is uitgevoerd (mensen zijn vooraf onvoldoende opgeleid/geïnformeerd/meegenomen/etc.).

Inclusief de haakjes heeft je zin een totaal andere betekenis en is die m.i. niet juist. Dat is alsof je zegt dat messen een probleem zijn omdat ze door sommige mensen op een manier worden gebruikt waar ze niet voor bedoeld waren. Agile is een werkvorm, je dient te weten hoe en in welke situatie je die het best kan toepassen.

[Reactie gewijzigd door pixeled op 3 april 2026 16:57]

[eggsforpedro]

Deze hele zin slaat nergens op. “Rekenen is het probleem, omdat niemand snapt hoe je moet rekenen”. Nee, dan is rekenen niet het probleem, dan is het probleem dat niemand snapt hoe je moet rekenen.

[Vayra]

Tegenwoordig is dat wel de logica. Er is toch een tool voor?

Waarmee ik niet wil zeggen dat ik het met je oneens ben

[Reactie gewijzigd door Vayra op 4 april 2026 19:35]

[kdekker]

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

[Croga]

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.

[synoniem]

Als kwaliteit de verantwoordelijkheid is van hetzelfde team wat de functionaliteit realiseert heb je de situatie dat de slager zijn eigen vlees keurt. Dat kan werken maar zal bij een hoge werkdruk al snel verwateren. En geldt overigens voor elke werkwijze agile, waterval, whatever. En voor meer branches dan softwareontwikkeling er is een reden dat bouw- en woningtoezicht bij gemeentes weer versterkt worden. Daar bleek dat het over laten aan de bouwers ook niet bevorderlijk was voor de kwaliteit van constructies.

[Croga]

Proberen similis te maken tussen software engineering en andere zaken is nooit zinnig.
Als een software engineer slechte kwaliteit levert dan kan hij het morgen zelf weer oplossen. Een slager heeft dat probleem niet.
Daarnaast is ook de slager verantwoordelijk voor zijn eigen kwaliteit. Een software engineer die zorgt dat er goed getest wordt is niet vergelijkbaar met een keuringsdienst die de slager keurt maar met een slager die zorgt dat er goede hygiene op zijn werkplek is. Hetzelfde met bouw- en woningtoezicht; die zorgen niet voor kwaliteit, die zorgen voor controle.

Dus nee, je vergelijking gaat niet op. In ieder vakgebied zorgt degene die werk levert dat dat werk de juiste kwaliteit heeft, in software engineering zou dit niet anders moeten zijn. De controle wordt vanzelf door de gebruikers gedaan....

[synoniem]

Bouw- en woningtoezicht zorgt voor kwaliteitscontrole. De keuringsdienst doet een kwaliteitscontrole op de toegepaste hygiëne en op de minimale kwaliteitsnormen voor vlees. Zo bijzonder is de softwarebranche niet, even afgezien van het ontbreken van geïnstitutionaliseerde kwaliteitscontrole.

Ik ben zelf betrokken geweest bij de ontwikkeling van uiterst kritieke software waar veel mensenlevens van afhangen en was heel blij dat er degelijke interne en externe kwaliteitscontroles op uitgevoerd werden. Gewoon omdat softwareontwikkeling mensenwerk is.

[DdeM]

Een keuringsdienst doet geen kwailteits controle, die kijkt, vaak steekproefsgewijs, of de kwaliteit eisen worden nageleefd en of hier controle op gedaan wordt. Ze blokkeren ook niet de oplevering van lopende projecten.

Wat dat betreft ben ik het er mee eens dat externe testers ook zo zouden moeten werken. Interne testers zouden daarentegen de controle moeten doen, maar dan wel als onderdeel van en in samenwerking met het team. Er is niets mis met een ontwikkelaar die zelf de tests schrijft, zolang dit maar in overleg gaat met de personen met de juiste expertise, dan hebben die personen ook weer meer tijd om andere cruciale onderdelen te checken.

[Croga]

Maar dat is toch precies wat ik zeg?

De bouw is nogsteeds verantwoordelijk voor de kwaliteit. De metselaar moet zorgen dat die muur stevig genoeg is, dat doet de controle niet, dat doet de metselaar.

Bij Software werkt dat precies hetzelfde; de software engineer moet zorgen dat zijn software kwalitatief goed is. Dat doet hij door tests in te bouwen. Dat is namelijk zijn enige manier om te controleren of het inderdaad goed is. Net zo goed als dat een fabriek zijn eigen producten test, een slachterij een lab heeft. Zo ook heeft een ontwikkelteam een set aan automatische tests om te blijven controleren of de kwaliteit goed is.

Daarnaast is software een behoorlijk stuk complexer dan bouw of hygiene. De context begrijpen is een groot deel van het proces. Proberen iemand anders, die dus níet in het proces zit, die context op dezelfde manier te laten begrijpen als het ontwikkelteam is waste. Puur weg gegooide tijd en geld.

[zordaz]

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.

[J_van_Ekris]

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...

[koppie]

Ja, de opmerkingen van Agile @Croga zijn zeker valide, maar de schaalgrootte, het aantal afhankelijkheden en de exponentiële mogelijke problemen maken het invoeren van échte agile ontwikkelmethodes waarschijnlijk heel lastig. En het feit dat ze dit al sinds 2015 aan het doen zijn, vind ik ze niet valide voor het ontwikkelproces van MS Windows.

[Ed Vertijsment]

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.

[bazs2000]

Een probleem met agile is vaak dat er eilanden ontstaan zonder dat er goede onderlinge communicatie is.

Op papier is agile werken heel mooi maar in de praktijk gaat het er vaak minder rooskleurig aan toe. Leuk een releasetrain maar als één team iets niet op tijd kan afkrijgen voor project X en het andere team op een gegeven moment maar doorgaat met project X dan is dat vragen om problemen. En dit gebeurt echt vaak.

Wat ik mij afvraag is hoe jij erbij komt dat agile niet het probleem kan zijn. Dat is gebaseerd op aannames zoals het artikel ook baseert op een aanname. En dat je nog toevoegt dat grote bedrijven (en Tweakers) geen flauw idee hebben hoe softwareontwikkeling in elkaar steekt is een zeer baude stelling en wederom, een aanname.

Even terzijde en niet zozeer naar jou gericht, deze is meer algemeen:

Wat mij opvalt bij bedrijven waar agile wordt gewerkt is de wijze waarop ceremonies worden ingezet en hoe krampachtig vaak aan het 'agile gedachtengoed' wordt vastgeklampt. Ook bij trainingen, Agile is goed en waterval is slecht. Waterval is per definitie slecht en bij trainingen wordt er bijna in gestampt dat Agile de enige goede werkwijze is. Dat is de grootst mogelijke onzin en ik heb het een keer aangedurfd een aantal praktijkvoorbeelden vanuit ons bedrijf aan te halen waar waterfall toch echt de beste werkwijze was.

Toen vroegen zij of ik wat filmpjes wilde kijken over de verschillen en na 2 van die filmpjes haakte ik af. Het lijkt soms wel op een soort van geloof. En Ik heb dit bij meerdere (grote) bedrijven met eigen ogen gezien. Niet via via, niet vanuit een verslag, met eigen ogen.

En microsoft ook blijkbaar op de 'trein' gestapt.

[CAPSLOCK2000]

Waterval is per definitie slecht

Historisch gezien is dat correct. De term 'watervalmodel' is bedacht om aan te geven hoe het níet moet. Je zegt precies goed dat waterval /per definitie/ slecht is.

Het is heel ongelukkig dat die term tegenwoordig gebruikt wordt alsof het een realistische aanpak is. Natuurlijk zijn er elementen die wel werken, maar zodra je het over 'watervalmodel' hebt is de implicatie dat het gaat over een aanpak die níet goed werkt.

(Het is een beetje vergelijkbaar met de term 'big bang', die bedacht is om die theorie over het ontstaan van het universum belachelijk te maken. Met dat verschil dat er tegenwoordig veel steun is voor het bigbang-model onder vooraanstaande wetenschappers).

[GeroldM]

Ben zelf werkzaam in een een bedrijf waar developers absoluut niet hun eigen code mogen testen. De reden daarvoor is dat een tester bepaalde ontwerp-eisen anders kan interpreteren en daarvoor dus test-scenarios bedenkt die de code heftig kunnen len crashen.

Is dit een snelle manier van ontwikkelen? Nee, dat is het zeker niet. Maar sinds we dit toe zijn gaan passen, is het aantal ernstige fouten in code sterk afgenomen. Want de programmeur kan iets heel anders begrijpen dan dat de klant wenst.

Het is ook standaard hier dat je de ene sprint als programmeur aan de slag bent, de andere sprint als tester. Dat om alle koppen zo snel mogelijk dezelfde kant op te laten wijzen. Sommige personen kunnen daar tegen, anderen niet en die mogen dan al heel vlug op zoek naar een andere werkgever.

Waterfall/Agile, als de koppen niet dezelfde kant op wijzen, dan hebben beide methodes zeer verschillende maar net zo destructieve manieren om projecten te laten falen.

[DigitalMesh]

tweakers is een manusje van alles dus dat hier niet alles 100% geschreven wordt zoals jij wilt of het hoort ja dat kan hé. Maar zeggen dat als Tweakers het niet snapt een mega tech giant het ook niet zal snappen is echt op zn kop lol.

[StackMySwitchUp]

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

[walteij]

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.

[DevWouter]

Het meest frustrerende is dat de waterval methode ook nooit echt bestaan heeft. Het is vooral een theoretisch model dat werkt onder perfecte informatie, perfecte planning, en perfect uitvoering. Zodra er een fout zit in de informatie, planning, of uitvoering wijkt men al af van het model.

Het werd toen de tijd gepromoot als de "ideale methode" waarbij men vergat te melden dat de statistische kans op succes nagenoeg 0 is.

In andere woorden: Software ontwikkeling is altijd een iteratief proces geweest. En eigenlijk kan dit over elke vorm van arbeid gezegd worden.

[CAPSLOCK2000]

Het meest frustrerende is dat de waterval methode ook nooit echt bestaan heeft. Het is vooral een theoretisch model dat werkt onder perfecte informatie, perfecte planning, en perfect uitvoering.

Zelfs dat niet, het watervalmodel werd voor het eerst gebruikt om uit te leggen hoe het niet moet. De eerste keer dat het beschreven werd was dat als pleidooi voor iteratief ontwerp.

https://web.archive.org/w...38p/Process/waterfall.pdf

[Darksteel83]

Ik werk zelf in de industriële automatisering. Daar werkt het waterval model voor een deel best wel redelijk. Maar voor andere delen heb je een iteratief proces nodig.

Het deel waarvoor het waterval model goed werkt/werkte is het deel wat overeen moet komen met de fysieke componenten in de fabriek. Als dat wijzigt heb je ook veel kosten in fysieke aanpassingen. Die kosten zijn vaak veel hoger dan voor de software.

Bijvoorbeeld als er in werkelijkheid 5 pompen en 10 kleppen zijn in een fabriek dan moet je ook 5 pompen en 10 kleppen hebben in je industriële automatisering software.

Vroeger had je dan voor iedere pomp dan ook bijvoorbeeld nog deze IO die bedraad werd.
Per pomp een Digital Input en een Digital Output . (FeedBackRun, Control)
Per klep, 2 Digital Inputs en 1 Digital Output. (FeedBackOpen, FeedBackClose en Control)

Bij oudere industriele installaties zie je die IO nog steeds best vaak. Bij nieuwere installaties heb je vaak per pomp een frequentie regelaar. Die je via een netwerk verbinding aanstuurt. Bij kleppen heb je nu ook steeds meer netwerk verbindingen.

Voor de aansturing van het geheel heb je wel vaak een iteratief proces nodig als dit niet gelijk al duidelijk genoeg is.
Als je echt pech hebt dan moet word het aanstuur process goed maken een heel iteratief project. Omdat je dan in de software dingen moet gaan oplossing die eigenlijk fysiek niet goed/slim zijn bedacht of gemaakt. Waardoor je software heel complex wordt.

[Chris_147]

Je hebt in theorie gelijk als je zegt: "Kwaliteit is de verantwoordelijkheid van hetzelfde team wat de functionaliteit realiseert en niemand anders."

Echter kan 1 team (van rond de 7 personen) dat niet bolwerken voor zo'n groot product als Windows. 1 Team werkt namelijk niet aan het volledige product. En je kan de kwaliteit van je eigen deel niet volledig garanderen zonder het volledige product geïntegreerd te testen.

Ik herinner me een presentatie van (denk ik) Mark Russinovich van net na 2000, waarin het aantal ontwikkelaars en testers in het Windows departement werd aangegeven. Voor NT 3.51 waren er dubbel zoveel ontwikkelaars als testers (enkele honderden) Voor Windows XP waren er ongeveer dubbel zoveel testers als ontwikkelaars. (enkele duizenden!) Die waren bezig met testen van Windows op allerlei systemen, met allerlei software en verscheidene versies daarvan. Als je verwacht dat dat binnen een team wordt gedaan, dan ben je de hele sprint aan het testen. En kan je waarschijnlijk nog niet doen wat dat test team deed.

Achter de Agile mindset kan ik me helemaal scharen, maar in mijn ervaring is het moeilijk schaalbaar. En dan krijg je gedrochten als SAFe, LeSS, SoS, DAD, ...

[Raymond Deen]

Mooie uiteenzetting.

Ik zie vaker dat agile als één of andere magische oplossing wordt genoemd, er hele afdelingen overhoop worden gehaald met een halfslachtige implementatie die niet door het personeel dat het zou moeten doen, wordt begrepen en geaccepteerd. Dat is heel erg jammer, want samen met een groepje mensen heel snel allerlei functionaliteiten bouwen en uitrollen is echt mooi om mee te maken. Maar als er dan kleinere en grotere wijzigingen tegelijkertijd door elkaar heen lopen, gaat het al snel mis. Men krijgt last van elkaars wijzigingen en pull requests, regressiefouten ploppen omhoog als paddestoelen en productiviteit valt flink terug.

Agile is dus misschien simpel, maar zeker niet simpel inzetbaar. Het is vaak een complexe wijziging in werkwijze en organisatie die je niet zomaar over afdelingen kunt uitstorten, maar zorgvuldig moet opkweken. Doe je dat niet, dan is het gedoemd om in het laatje met gefaalde oplossingen terecht te komen.

Iedereen die er, al is het maar zijdelings, bij betrokken is moet je dan ook vanaf het eerste moment mee zien te krijgen.

[GertMenkel]

Een "gedegen kwaliteitsafdeling" is de doodsteek van kwaliteit in een agile omgeving.

Wat een onzin. Als de kwaliteitsafdeling in dezelfde of volgende sprint alle issues valideert, heb je snelle feedback en agile ontwikkeling. Een toegewezen afdeling die de kwaliteit in de gaten houdt ondermijnt op geen enkele manier agile werken.

Juist als je alle teams alleen maar hun eigen gedeeltes laat testen, krijg je de onzin waar Microsoft mee te maken heeft. Voor een goed besturingssysteem heb je teamoverschrijdende integratietesten nodig. API's en applicaties moeten op elkaar aansluiten, anders ga je ten onder aan aannames en verschillende interpretaties van specificaties.

[rjmno1]

Mijn nero doet het niet meer omdat deze updated drivers ontbreken tevens doet de unreal tournament 99 inmiddels ook niet meer.Alleen al omdat de drivers door microsoft goedgekeurd moeten zijn niks doet het meer dat ze maar eens snel met een update komen waardoor dit gefixed wordt.

[tweaker29789]

Agile software engineering klinkt altijd fantastisch op papier. Maar ik heb nooit begrepen hoe dit een QA overbodig kan maken. Soms heb je nl. gewoon een verse groep ogen nodig om de fouten , maar vooral ook de onhandigheden in UX design te zien. Developers kijken vaak toch anders naar software, dan gebruikers.

[Whiskeyjack]

agile is het probleem

[ppheijnen]

Helemaal mee eens lijkt er op dat terminologie wel is toegepast bij microsoft maar daadwerkelijk uitvoering gewoon waterfall is gebleven.. Herkenbaar vanuit eigen ervaring bij ander Enterprise groot bedrijf

[m-a-r-t-1]

Dit is dan ook precies hoe ik Agile de afgelopen tien jaar in de praktijk gezien heb. Er wordt ergens aan gestart en onderweg wordt er wel bekeken hoe de boel weer werkend wordt gemaakt. Leuk als je een 24/7 productie fabriek hebt. Agile werkt gewoon niet in de praktijk. Het heje fundament ervan nodigt uit om te weinig aan toekomstige problemen en belangrijke details te denken.

[Goosmeister]

Zelf ben ik scrum master (is dat handig om dat nu te zeggen? 🤔) en het Agile werken zou juist een kwaliteits verbetering moeten brengen doordat er kort cyclisch geleverd wordt (in het geval van Scrum). In het artikel staat ook dat er op testen veel bezuinigd is, door ai veel software wordt gegenereerd en developers hun eigen software testen. Zonder gehinderd te worden door kennis van de interne structuur van Microsoft dan zou je zeggen dat hier iets niet goed gaat.

[MallePietje]

Agile is hier niet het probleem.

Werk je zelf aan Windows updates bij Microsoft?

Agile is in mijn beleving een soort religie. De wijze waarop je dat in de praktijk zou moeten brengen is dusdanig zwak geformuleerd, dat de praktische waarde beperkt is. Dat lijkt een bewuste keuze: Als een Agile implementatie faalt, kunnen de voorvechters altijd claimen dat het iemand anders schuld is en vooral niet aan de Agile filosofie ligt.

Wat ik zie is dat een Scrum aanpak heel populair is. Een product wordt incrementeel aangepast. Wat je na verloop van tijd ziet is dat een product allerlei pukkels en puisten heeft gekregen, waardoor het onderhoud problematisch wordt. Dat is geen kwestie van een beetje tech debt oplossen, maar de hele opzet/architectuur voldoet eigenlijk niet meer aan de gewijzigde wensen. En natuurlijk hoeft dat in theorie weer niet te gebeuren, maar het is wel een situatie waar de hele werkwijze op aanstuurt. Gewoon doorgaan met sprints, totdat de shit hits the fan.

[cmegens]

Wat gewoon zonde is is dat er onder de Tweakers in de community heel veel kennis en ervaring is over deze processen, maar dat de journalisten van Tweakers er dus blijkbaar niet aan willen om daar eerst inzichten op te halen alvorens ze een dergelijk artikel publiceren. De community is juist wat Tweakers uniek maakt, maak er dan gebruik van!

[segil]

Ongetwijfeld dat het de laatste tijd wat vaker mis is met Windows updates, maar laten we ook niet overdrijven. Het grootste deel van de Windows gebruikers heeft hier helemaal geen last van. Tweakers besteed imho onevenredig veel aandacht hieraan, wat er toe kan leiden dat mensen denken dat het dramatisch is gesteld met het OS. Wat het gewoon niet is, het werkt prima in de basis. (los van wat je vindt van verplichte Microsoft accounts en copilot integratie).

Ik heb in het verleden vaker de redactie getipt over serieuze bugs in mac-os en Linux, met een zeer hoge score. Maar die haalden het nieuwsoverzicht niet. Maar zodra een Windows icoontje een andere kleur krijgt, komt daarover weer een artikel. Er komen 10+ artikelen over het einde van Windows 10 updates en 50+ artikelen over de vermeende hardware eisen die aan Windows 11 gesteld worden of de online account plicht. Raar genoeg geen artikelen over dezelfde plicht bij ChromeOS of iOS.

Tweakers mag zichzelf ook wel eens de vraag stellen of ze niet teveel aandacht besteden aan Windows, hoe onbevooroordeeld ze zelf wel/niet zijn in hun berichtgevingen en waarom ze zo weinig berichten over bugs in Linux en mac-os.

[Reactie gewijzigd door segil op 4 april 2026 09:31]

[Olympus user]

Je hebt op zich wel een punt, echter als er een bug in Linux of mac-os zit is de impact vele malen kleiner dan die in Windows.

[tweaker29789]

De schrijver van dit artikel lijkt dit ook te vergeten, maar aangezien linux/gnu dominant is op het gebied van server infrastructuur, lijkt me dat een bug in linux ook behoorlijke impact kan hebben.

[Olympus user]

Op servers is het zeker een ander verhaal dan op pc's.

[iAR]

macOS en Linux zijn nu eenmaal kleiner. Daarnaast komt ook daar echt wel nieuws van op de pagina. Dat Windows weer een icoontje veranderd maar andere steken in zijn OS niet aanpakt, is opzich wel nieuwswaardig. Het toont aan dat Microsoft meer bezig is met looks dan een efficiënt en werkbaar OS. Op kantoor is de combi Windows 11, Onedrive, Microsoft 365 en Teams nu niet het paradepaardje van productief en efficiënt werken… maar goed, dat gaat over ontwerpkeuzes niet over updates.

[FrostHex]

Mooi artikel en vandaar dat m’n volgende laptop weer een Mac wordt, daar heb je gewoon veel minder gedoe met drivers en updates. It just works.

[Reactie gewijzigd door FrostHex op 3 april 2026 10:10]

[PolarBear]

Er is echt geen systeem waar ik serieus mee gewerkt heb waar er niet een keer een update was die niet goed liep/vast liep/bugs veroorzaakten. 25-30 jaar geleden met Cisco IOS waar je allerlei branches/trains had waar een update er soms voor zorgde dat functionaliteiten verdwenen of bugde, tot nu met Fortigate waar de nieuwste branch ook altijd spannend is. Maar ook Mac OS X updates die niet lukte, Linux updates, Windows updates. Allemaal wel een keer misgegaan.

En heel eerlijk, er zijn heel veel berichten over Windows Updates die misgaan, maar mijn indruk is dat het altijd maar een kleine subgroep is waar het misgaat. Ik heb de laatste jaren met 100+ devices onder mijn management eigenlijk niet tot nauwelijks proberen gehad met Windows Updates (nou ja als een user zijn device midden in een update uitknalt kan het nog wel eens stuk gaan).

[FrostHex]

Klopt maar op de Mac veel minder, want ze hoeven geen rekening te houden met 100.000 verschillende configuraties. Dat is het voordeel van de Mac waarbij er maar een beperkt aantal systemen zijn en ze dat ook nog eens zelf maken.

[segil]

en het feit dat het veel minder gebruikt wordt, dus veel minder interesant voor hackers om een bug in te vinden.

[segil]

Klopt helemaal. Windows krijgt overdreven veel aandacht op Tweakers en wie alleen Tweakers gebruikt als bron van IT informatie denkt al gauw dat het allemaal kommer en kwel is met Windows. Tweakers bericht veel minder over bugs in Linux of mac-os, ondanks dat die er wel zijn.

[desalniettemin]

Maar Windows heeft de laatste tijd constant update problemen die weer een update nodig hebben om probleem van die update op te lossen enz. Vroeger hadden ze een team die de updates eerst uitgebreid testten voordat ze uitgebracht werden, maar dat team schijnt ontslagen of meer dan de helft gedecimeerd te zijn. Updates worden dus te vroeg uitgebracht, vandaar huidige problemen.

[Bor]

Vroeger waren er ook issues met updates, niet alleen bij Microsoft. Updates worden nu ook nog gewoon getest of denk jij dat updates zonder enige controle zo de wereld in worden geslingerd? Naast dat Microsoft gewoon zelf test kennen we al langere tijd zaken als preview updates etc.

[derx666]

Ik was het gezeik met Windows sinds Windows 11 helemaal zat, en heb vorige week een MacBook Pro gekocht. Had ik 3jr eerder moeten doen. Blijft fijn om een laptop te hebben die gewoon werkt als je hem openklapt, en waar je niet eerst 30s moet wachten totdat hij uit hibernate is wakker geworden (omdat sleep al jaren stuk is).
Windows zal echt nog wel z'n plaats hebben op vlakken, maar met Windows 11 hebben ze de plank gewoon echt misgeslagen. Het is belachelijk dat je op een Ryzen 5600h + 32Gb + 3060 nog steeds stotterende scroll hebt. CPU fans die ineens 100% gaan vlammen omdat je CPU 90C is terwijl je alleen een browser open hebt, en er geen proces is wat meer dan 10% cpu gebruikt.
Denk dat ik op de Macbook de fan 1x gehoord heb. Dat was terwijl ik wat aan het vogelen was met UTM en x64/x86 emulatie. Verder is m'n gebruik eigenlijk niet veranderd...

[Rainboww]

Ik ga je volgen, ook hier sloopte een recente Windows update mijn systeem. En nu weigert ie (na een in-place reinstall) te upgraden naar 25H2. De Macs zijn wel wat duurder, maar dat heb ik wel over voor een stabiele omgeving. Ook naar Linux gekeken overigens, maar constant probleempjes waar je tegen aan loopt gaan troubleshooten is niet mijn ding.

[derx666]

Ja en nee... Zakelijk moest m'n collega recentelijk een nieuwe laptop uitzoeken. Als het een Windows laptop is moeten we HP bestellen. Als je dan gaat kijken voor een beetje een non gaming model met dedicated graphics kom je uit bij een Elitebook of een Zbook. De meesten hebben nu nog een Zbook (me included). Wil je dan een 32Gb model met een 1T SSD en een Nvidia A1000 dan zit ja al snel tegen de 3K euro aan...
Ik heb nu aangeboden dat hij mijn (vrij nieuwe) Zbook mag hebben, dan bestel ik zakelijk ook een MacBook Pro, dan met 32Gb, en ben ik voor minder dan 2500,- klaar.

[GertMenkel]

Nou, mijn ervaringen op zakelijk gebied zijn niet heel veel beter op macOS dan op Windows. Beide hebben gewoon problemen, door slordigheid of door procesfouten.

Ik had de hoop dat macOS nu wél ineens een keer een OS zou zijn dat alle onzinproblemen zou moeten voorkomen (Apple verbiedt tenslotte dingen die op Windows veelal voor instabiliteit zorgen, zoals bepaalde kerneluitbreidingen), maar dan kom je jarenlang bekende bugs tegen als "update loopt vast als je laptop aangesloten is op een extern scherm".

Ieder mag zijn voorkeur hebben en de hardware die Apple levert vind ik zelf een goede reden om ze bij de volgende aankoop boven Windowslaptops te verkiezen, maar qua bugs en stabiliteit zie ik geen overduidelijke winnaar. Het zal aan de software die je gebruikt liggen welke bugs je leven wel of niet zuur gaan maken.

[wiseger]

Die winnaar is er wel en de reden is ook volkomen duidelijk. Het is een wereld verschil of je te maken krijgt met allerlei drivers dan derde partijen of dat je als onderneming alles zelf in de hand hebt.

Microsoft communiceerde al vele jaren geleden dat het meerendeel van de blue-screen-of-deaths veroorzaakt werden door brakke drivers van derde partijen.

De keuze is ook duidelijk, wil je als gebruiker controle over je hardware en zelf bepalen wat je in de computer steekt of leg je je neer bij de keuzes die de fabrikant voor je maakt waarmee je een stabieler systeem krijgt?

[GertMenkel]

Die winnaar is er wel en de reden is ook volkomen duidelijk. Het is een wereld verschil of je te maken krijgt met allerlei drivers dan derde partijen of dat je als onderneming alles zelf in de hand hebt.

Dat was mijn verwachting ook, maar die verwachting heeft Apple niet waar kunnen maken. De zakelijke Windows-11-laptops van HP zijn in mijn ervaring net zo stabiel als de laptops van Apple. Drivers van derden of niet.

Het niet downloaden van gekke gamedrivers of vage hardware zal al een heel stuk helpen, de WHQL-drivers die via Windows Update binnenkomen zijn retestabiel in mijn ervaring.

[wiseger]

Windows 11 werkt met WHQL drivers. Dat doet Microsoft niet voor niets, juist om de problemen die men had het hoofd te bieden. Keerzijde is overigens wel dat veel apparatuur en insteekkaarten daarom niet met Windows 11 meer werken terwijl ze goed functioneerde onder Windows 10.

HP en Dell werken net zoals Apple met beperkte configuraties. Zo kunnen zij de stabiliteit waarborgen.

[GertMenkel]

Ook Windows 10 had WHQL-drivers, het WHQL-programma bestaat tenslotte al sinds Windows 95. Veel oudere WHQL-drivers werken ook op nieuwere versies van Windows.

Qua drivermodel zit er niet heel veel verschil tussen Windows 10 en Windows 11. Printers zijn aangepakt en een aantal apparaatklasses zijn aan het user mode-model toegevoegd, maar als er iets kapot gaat verwacht ik eerder dat het om een Windows 7-driver ging die het tot en met Windows 10 gehaald heeft dan dat het een Windows 10-driver is die op Windows 11 niet meer werkt.

[jip_86]

Het is maar net wat aansluit bij jou wensen en eisen denk ik. Het het een keer geprobeerd maar ik kon er niet mee werken. Een heleboel andere mensen wel en dat is prima. Dat is het mooie aan keuze hebben.

[ShadLink]

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)

[Croga]

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.

[skaars]

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]

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.

[segil]

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.

[TRS-3]

Het grootste verschil zit 'm in de drivers. Omdat Apple zelf de hardware samenstelt en in combinatie met z'n eigen OS verkoopt, is het aantal mogelijke combinaties relatief beperkt. Windows moet een enorme hoeveelheid hardware ondersteunen, en die combinaties kunnen voor systeemcrashes zorgen.

En waar zoals in het artikel beschreven vroeger jaren van testen "in het wild" werd gedaan, is de ontwikkelcyclus ook nog eens enorm versneld en zijn mensen met specifieke testkennis wegbezuinigd. Dus is een release tegenwoordig praktisch de beta-test :-)

[Dekar]

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.

[segil]

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?

[Dekar]

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.

[segil]

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.

[Zebby]

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.

[Visgek82]

Never nooit problemen gehad met een update. Alles werkt als een zonnetje

[Craysv2]

Graapig deze morgen nog een device gehad, die na update niet meer wilde booten.

[Klauwhamer]

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.

[CriticalHit_NL]

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.