One simple but monolithic codebase vs many clearly documented dependencies

Question

Often when beginning a new project, I start out with what I believe to be the best of intentions in terms of how to structure the codebase. I love the idea of numerous small modules that do one thing well, are de-coupled from other parts of the codebase, and could potentially be reused by myself in other (similar) projects or open sourced for others to take advantage of.

However, come crunch week when I'm actually trying to get something into production, there's been more than one occasion where the complexity of managing all these different modules has proved too much of an overhead (despite good documentation and deploy methodology). On those times I've simply changed tack and bundled all the modules into one repository and managed it all as one codebase, meaning I can track everything together through different branches, deploying to staging and test environments, etc...

What are the advantages and disadvantages of these different approaches, and how do you manage working in one way or the other?

Advantages of one monolithic codebase:

• Easy to deploy
• Easy to rollback
• Easy to branch/manage all changes together
• No (or less) potentially complex dependencies to document and manage

Advantages of modular dependencies:

• Reusability
• Clean architecture (one module does one thing well)

Answer 1

I do not see the opposites as much as you do. Taking a .NET experience as an example, I can ensure parts of my code are geared towards well-defined responsibilities, I can structure my codebase into namespaces, ensuring that the touching points of the namespaces are well defined and that classes within the same namespace really do belong together.

However, all this can happen within a single unit of deployment, single project, branch, what have you. If you stick to that, units of code that may become reusable in the context of the projects you do will crystallize and that would be the point where you may decide to introduce a new unit of code, with its own deployment artefact, source control branch, etc.

Answer 2

Here is a talk from Google explaining (a little bit) how they handle their gigantic monolithic code repository. And why they have one.

By the way, I don't think it has to be opposed to a well defined set of dependencies. I would even say that to handle a monolithic codebase, you have to be super careful with the dependency graph and the responsibilities. Because with this kind of organisation, it is easy to add a lot of more or less useful deps…