In Tinder’s case, deep inter-dependencies between those targets stretched what engineers call the critical path, which is the longest chain of dependent tasks that determines how long a build takes.
I’m not surprised by "modularization good" – I'm more intrigued by how Tinder had to be so disciplined to do it without it becoming a 2-year yak shave. Most organizations say they want to break-up the monolith, but allow people to continue adding new code to the old target; I think the real killer is the policy change at the end: no new files can go into the monolith.
I liked the idea of using compilers to drive modularity, but I need to point out that most teams are not mature enough with their build toolchains to trust automation on this level at scale. Many of the mobile repositories I see have unreliable CI for main, never mind deterministic, replayable transforms across thousands of files. While "Six Months vs Twelve Years" is great marketing, the reality is there was a ton of boring pre-work done before this could happen: standards around Dependency Injection (DI), boundaries, access controls, and an engineering culture that would tolerate large-scale refactorings in their branch environments all had to be established.
As a follow-up, I'd rather hear less about "this is how we did the high-level plan", and more about "this is what really broke": where the graph failed to accurately represent dependencies, where the access-control changes caused new problems, how they managed teams that refused to abandon their quick fixes, etc. Still, this is probably one of the few monolith breakup stories that appears to be a real, replicable process and not simply "we just slowly rewrote everything over 5 years," which makes it incredibly valuable.
Can you show an example of how to automate the process of moving files?
I’m not surprised by "modularization good" – I'm more intrigued by how Tinder had to be so disciplined to do it without it becoming a 2-year yak shave. Most organizations say they want to break-up the monolith, but allow people to continue adding new code to the old target; I think the real killer is the policy change at the end: no new files can go into the monolith.
I liked the idea of using compilers to drive modularity, but I need to point out that most teams are not mature enough with their build toolchains to trust automation on this level at scale. Many of the mobile repositories I see have unreliable CI for main, never mind deterministic, replayable transforms across thousands of files. While "Six Months vs Twelve Years" is great marketing, the reality is there was a ton of boring pre-work done before this could happen: standards around Dependency Injection (DI), boundaries, access controls, and an engineering culture that would tolerate large-scale refactorings in their branch environments all had to be established.
As a follow-up, I'd rather hear less about "this is how we did the high-level plan", and more about "this is what really broke": where the graph failed to accurately represent dependencies, where the access-control changes caused new problems, how they managed teams that refused to abandon their quick fixes, etc. Still, this is probably one of the few monolith breakup stories that appears to be a real, replicable process and not simply "we just slowly rewrote everything over 5 years," which makes it incredibly valuable.
Fascinating, I trully reflect on how unclear goals are the silent killer of so many promising AI initiatives.