|
|
|
|
|
|
by djur
905 days ago
|
|
|
In most cases there's going to be substantial overlap between the functionality required for various business functions, and even in differentiated systems the ideal technical domains may not map cleanly to business domains. It's very easy for this to result in multiple teams having half-assed, semi-compatible implementations of the same functionality. Some places try to address this by creating dedicated "core" or "platform" teams, but there's numerous pitfalls this way as well. Platform teams and product teams necessarily have to justify their budgets in different ways. They have different stakeholders and internal sponsors. This can result in political struggles over headcount. "Brain drain" scenarios where product teams are perennially starved as their strongest ICs are moved to platform. "Slush fund" scenarios where platform teams are regularly "temporarily" reassigned to support feature development. I've seen them both. The longer you can have your entire engineering team share responsibility for the entire product the better. I am convinced of this. Unless you can truly, completely decouple systems -- making them separate products with dedicated teams -- you run a high risk of having a codebase that is more complex that people still need to understand in its entirety to work effectively. The worst of both worlds. |
|
|
Exactly what I meant. And to make it happen you need to understand underlying business domain. Separate product doesn't have to be huge.