While I agree that maintaining one codebase is preferable, the 'teams' part is a bit off.
No-one wants 'three teams building one product' which is why it almost always is far better to have one team with android, iOS, web and desktop mixed. Obviously if their mixed erpertises are around one codebase, that is even better.
But then there's the problem that now you have two teams - ops team doesn't understand the app and app team doesn't understand the ops/infra side. I of course agree with your point that there should be two teams but you need a few guys who understand both app dev and ops/infra/OSes/k8s internals etc. And finding these people has been nearly impossible.
Why can't you decouple teams form each other with modularity and encapsulation? I never worked in a team, but I could imagine that teams just have some agreements about interfaces and then work independently on a single code base but in a different classes and packages.
The problem this solves is having different teams in the same company perfectly happily developing away on their own stacks when a random business requirement needs that they get their components in the same browser window such that neither team is tied to the other's deployment cadence.
I think this really demonstrates how companies aren't monolithic, even ones that take pains to present a unified front like Apple.
One group wanted to implement a tool to improve child safety, another team wanted to enforce user privacy. At one point, the former was about to complete their project, but was stymied by the second. Of course, it's surely more complicated than "one team" vs "another team", but the concept of conflicting goals within the same entity applies. It's not some top-down dictat.
This really only works if you have at least one team dedicated to maintaining cohesiveness in design patterns across all the 'micro frontends'(i.e., one of those verboten 'horizontals').
Otherwise you are going to end up with a ux experience or even a UI experience that diverges from app to app as each team designs and implements its own solution to common problems
The app in the article is an interesting case. If you've got an app split like that, working backwards from Conway's Law tells us there are likely two separate teams working on it. Cutting the deployment in half may well allow each team to become more independent. That might be the real win.
Modules help some, but being tied to a deployment cadence with say, hundreds of other developers, can be very painful. Having to delay my team's features because another team broke the build doesn't help my customers. Isolating CI pipelines by team can help that somewhat, but you still end up sharing fate with teams with whom you might have no real interdependencies.
This. This is so often overlooked. Getting your architecture to roughly align with your team structure can do wonders, even if there's only a hallway dividing people. When a small team can iterate and evolve a chunk of code independent of anyone outside the team, it really unshackles them.
There are obviously patterns for doing this in monoliths (or, say, mobile clients - another type of monolith), but at some point you are bound by the dependencies inherent in a single runtime.
We've pushed our team sizes to the max and we have to hire more. The only reasonable step I see is splitting the app across two teams.
This must be the norm for large apps at large companies (I've never worked for one.) My current strategy is based on keeping one team over a core set of functionality. Then dividing the rest of the Views/Services based on feature set across the teams.
Any resources on this problem would be appreciated.
Especially for games or OS development, you might have shifting toolchains and SDks. Different teams may move out of sync because different teams want different things at a given time.
Inverse Conway's Law; organizations are encouraged to create isolated, disconnected teams in order to benefit from modular maintainable code with clear and distinct interfaces.
Could you explain the scenario you have in mind? If you're having trouble maintaining convention across teams producing different shared components, that seems likely to cause problems no matter how you end up deploying things.
(This is similar to the argument for containers with developers who aren't great sysadmins: they're usually making changes anyway and this way they don't have root on the host, etc.)
You end up with a Frankenstein application where different product areas feel like they were built by entirely different companies. There's a real price to giving that much autonomy to each development. You want teams to be empowered, but there has to be ground rules. Having to unwind the "every team had all the freedoms" and having dozens of databases and hundreds of microservices makes implementing anything cross-cutting (auditing, analytics) a slow-as-molasses multi-quarter initiative.
dividing the work between teams worked at first but as product grown it started to have dependencies between teams and it got messy. Eventually you need to implement functionality across team areas. one team is assigned to implement it and when it breaks in other areas - that team needs to ask the other teams to fix it... in short, dividing the product to different teams is not an optimal solution.
* Doing so in a way that still allows your entire app to appear to be a coherent whole is tricky.
reply