I definitely see these forces at work at my current gig. In our context the lines separating what should be domain-specific boundaries are blurry. The main syst

I definitely see these forces at work at my current gig. In our context the lines separating what should be domain-specific boundaries are blurry. The main system is a monolithic codebase which was developed with a "wild west architecture" for over a decade before engineering leadership realized the tech debt was interfering with feature development. We've tried to draw domain boundaries but that initial lack of discipline meant that things were too far gone to easily separate them, and senior leadership has never been willing to invest in paying down this debt. The points about shared tech and infrastructure hit pretty hard because it's a single monorepo deployed to homogeneous application servers. When we do bump up against issues with infrastructure we almost always end up building one-off shims. Our architects call them Microservices. Code contribution is messy too. For any given feature, core functionality is typically owned by one team along with some of the downstream effects. The rest of the downstream effects are owned by other teams scattered across different verticals and often continents. It's rarely safe to change the core functionality of a feature by itself. Dysfunctional politics leads to projects getting delayed because of miscommunication and different priorities, and we can't risk encroaching on someone else's fiefdom. I recently burned a lot of political capital doing just that because a critical deadline was at risk.