Partitions and Compositions

[aaronjensen]

https://github.com/aaronjensen/software-development/blob/master/partitions-and-compositions.md

[doughtnerd]

You have multiple applications, libraries, and services that are deployed and developed separately. They provide a cohesive experience to the end-user and you would like to combine them into a single deployable application.
Which of these do you think would be easier? Why?

To me, combining things that are separate would be easier and yes, coupling and entanglement are the main reasons I say this but I think it goes a little deeper. When a system is designed as a separate, autonomous component, the boundary (or domain) of that thing is well established. The benefit (that you call out) of "[boundary violation being] practically impossible" is incredibly beneficial. What often plagues monolithic codebases is the lack of enforced boundaries and without careful review from other team members, concerns can be too easily mixed and the boundaries blurred.

To me, software should be akin to lego bricks. Every piece has its single, specialized purpose and can be used in an infinite amount of constructions, just like in your screw analogy. When one builds a highly coupled system, it's like supergluing a bunch of legos together. The entire "chunk" has to be replaced or a great amount of expense & effort has to be expended to "uncouple" the bricks.

It takes more work to build separate libraries than it does to build everything into a single application, but only initially. There are two dimensions that are more challenging. The first is that you must learn new skills do to this, but that's something you have already spent a lifetime doing. The second is that it takes more effort up front to establish patterns and libraries for your specific project.

The second part of "establishing patterns" is the more difficult of these in my opinion. Especially in teams with high churn (or rapid growth), disseminating these patterns is I think one reason why linters/formatters are so prevalent though they only cover style, not programming patterns themselves. Whether a programmer prefers functional/procedural/object oriented or any other paradigm and how they code within it often varies wildly and each approach has its place.

[aaronjensen]

To me, software should be akin to lego bricks

I understand this analogy, but FWIW I avoid using anything related to toys when discussing our work. We don't need to self-infantilize, in my opinion. There's enough (understandable) perception of developers as immature.

Especially in teams with high churn

Why do they have high churn? One must solve this first.

or rapid growth

This is often indicative of a problem as well.

Whether a programmer prefers functional/procedural/object oriented or any other paradigm and how they code within it often varies wildly and each approach has its place.

Indeed, though I often say that if I can tell who wrote code in our project without looking at a blame, it's a problem.

[doughtnerd]

Indeed, though I often say that if I can tell who wrote code in our project without looking at a blame, it's a problem.

This is something that I definitely connect with. It remind me of my very short stint in game development. The artists all had unique styles they developed over years of practice but it fell both on them and the lead to ensure that stylistic consistency across the entire game was maintained, no matter individual preferences. When assets were added to the game that strayed, it was glaringly obvious and detracted from the overall quality of the game.