In general, "unity" is something software developers routinely pursue just for the sake of unity itself, failing to understand that unity comes with significant

In general, "unity" is something software developers routinely pursue just for the sake of unity itself, failing to understand that unity comes with significant tradeoffs. It is much harder to build a unified solution than a localized, one-off solution. Divide-and-conquer is often a much better engineering strategy: DAC might create more work than unity, but the work is more likely to succeed instead of falling apart because we failed to anticipate all the use cases within the unified framework, especially when we lack experience in the domain. Also refer to Jeff Atwood's Rule of Threes (which he borrowed from someone else) here.