Ik heb vorige keer al gezegd dat die 2weken echt compleet onrealistisch is en dat er echt wel meer tijd nodig was om het voor elkaar te krijgen. Meta zijn schatting van een half jaar was ook wel een beetje overdreven, maar 2 tot 3 maanden totaal vind ik echt niet gek gezien de enorme schaal waarop Facebook werkt.
supersnathan94 in 'Facebook moet zijn interface aanpassen - maar andere apps doen precies hetzelfde'
supersnathan94 in 'Facebook moet zijn interface aanpassen - maar andere apps doen precies hetzelfde'
Even wat technische achtergrond. Facebook gebruik een monorepository met mercurial. dat is dus niet GIT. De totale codebase van alle Facebook projecten staat hier in en die was in 2014 al significant groter dan bijvoorbeeld de linux kernel. In 2025 is dat alleen nog maar harder gegroeid door acquisitie en nieuwe producten. Ooit begonnen met
Git en
Subversion, stapten ze over op een zwaar aangepaste variant van
Mercurial om de schaal aan te kunnen (
engineering.fb.com).
Die interne Mercurial-versie werd later deels open-sourced onder de naam
Sapling, waarmee ontwikkelaars sneller kunnen werken in een near-monorepo-structuur (
developers.facebook.com/blog/post/2022/11/15/meta-developers-workflow-exploring-tools-used-to-code/).
De schaal is indrukwekkend:
duizenden commits per uur wereldwijd komen binnen in deze monorepo (
form3.tech/blog/engineering/delivering-at-scale-for-meta), met een release-pipeline die veranderingen binnen gemiddeld
4 tot 6 uur in productie brengt (
atscaleconference.com/scaling-releases-inside-meta-www-release-operations) of, zoals een engineer het samenvatte: “tens to hundreds of commits every few hours” (
infoq.com/news/2017/09/facebook-release-scale).
Nu zegt dat niks over de doorlooptijd van een feature natuurlijk, maar over het algemeen, in een normale corporate, is het niet gek dat een feature maken een maand tot anderhalf duurt. 0-1 sprint aan voorwerk om alle requirements duidelijk te krijgen vanuit business en klant, 1 sprint bouwen en intern/acceptatietesten en dan de verificatie bij de sprintdemo, en daarna ga je het uitrollen en zorgen dat het bij iedereen komt. Uiteindelijk inclusief externe wachttijden ben je dan gewoon 6 weken verder en dan mag er niks fout gaan.
Vergeet niet dat een app store traject ook nog tijd kost. Als er daadwerkelijk wat geüpdatet moet worden dan kost dat ook rustig een week om dat uitgerold te krijgen. Meta zal hier ook een veilige marge ingecalculeerd hebben om eventuele tegenslagen en issues binnen de gestelde tijd op te lossen. Je bent nog best afhankelijk van externe delivery systemen naar je klant toe (appstore, Playstore, Galaxy Store, AppGallery). Ik denk zelf dat ze ongeveer met 6 weken rekening houden, maar dat ze een mogelijke redesign in ieder geval niet uitsluiten:
Week 1/2: Ontwerp en fundament.
Teams bepalen waar de chronologische optie zichtbaar moet zijn en hoe de voorkeur van de gebruiker blijvend opgeslagen wordt. Backend-developers voegen de bestaande API-parameter toe aan een State store, terwijl de mobiele teams de eerste UI-concepten en toggles bouwen/overnemen (iOS heeft de optie immers al wel)
Week 3: Integratie en interne test.
De feature draait nu achter een interne flag en wordt getest door medewerkers (“dogfooding”). UX, legal en toegankelijkheidsteams controleren of alles voldoet aan de DSA-eisen en gebruiksrichtlijnen. A11y is hier namelijk ook van toepassing
Week 4: Canary-release en app-storevoorbereiding.
De eerste 1-5 % van de gebruikers krijgt de nieuwe feed, terwijl Android- en iOS-versies worden ingediend bij de stores. Telemetrie-dashboards bewaken crash-ratio’s en prestatieverschillen. Vooral verschuiving van Ad revenue gaat hier natuurlijk in de gaten gehouden worden.
Week 5: Opschalen en optimaliseren.
De feature wordt stapsgewijs uitgerold naar 25–50 % van de gebruikers. Feedback en bugmeldingen worden verwerkt, terwijl het team kleine performance-aanpassingen kan doen aan de feed-engine.
Week 6: Wereldwijde uitrol en afronding.
Alle platforms gaan live, documentatie en monitoring worden afgerond, en er blijft een kill-switch beschikbaar om snel terug te rollen bij problemen.
Wettelijk gezien ben je dan klaar, daarna begint mogelijk het verwijderen van de feature toggle. Dan is het dus daadwerkelijk het hele riedeltje nog een keer doen. Mocht er iets fout gaan dan heb je in ieder geval nog tijd om te schakelen.