Monorepo - A code organization approach that prioritizes customer centricity and collaboration in Engineering teams.

If I were to ask the answer to the Ultimate Question of Life, the Universe and Everything, I would not be surprised if quite a lot of the readers came back with 42. Finding the right answer nowadays is just one click away. If you are still struggling google "answer to the Ultimate Question of Life, the Universe and Everything".

In case Google's answer did not convince you, let me tell you that this answer was calculated by the supercomputer "Deep Thought" after seven and a half million years of thought. Yes, you read that correct, this is the outcome of 7 and a half million years of thought. If you find the answer shocking, well you are not alone.

This answer was so shocking that it resulted in the construction of an even larger supercomputer, named Earth, designed by Deep Thought, Earth was tasked with determining what the question was in the first place. If you are one of the curious one, who does not take an answer without critical thinking, I would assume you have already figured the connection. For the rest stop looking for the right answers and instead focus on asking the "right questions".

Heidegger's wrote in great detail about this trap in his early work "Being and Time". He writes, being authentic does not require some exceptional effort or discipline, like meditation. Rather, it entails a kind of shift in attention and engagement, a reclaiming of oneself, from the way we typically fall into our everyday ways of being. This is in contrast with Descartes notion of intelligence that he conceived as abstracted away from all worldly stuff. Heidegger doesn't buy that. For him, humans are embedded into a world and hence our experiences consists of engagement with the world. The answers each one of us arrive might not be same and so its not about finding the right answer but more about asking the right questions.

Being authentic does not require some exceptional effort or discipline, like meditation.

So what is the relevance of a Monorepo and code organization with the Heideggarian thought. The connection starts to emerge when you think deeply about how you want to organize the code for your organization.

Monorepo is a version-controlled organization of code in a single repository that are run by different teams. It should not be confused with monolithic architecture and contains functionally independent code logically organized under sub-folders that could be deployed and scaled independently, like any microservice would.

The alternative and more popular style of code organization is Multirepo in which case each project has its own dedicated code repository with its deployment and build pipelines. At the surface it might not seem like a big deal, but the choice one makes here, creates a huge impact on the DNA of your company and outcomes it creates. If as a company you believe in customer centricity, delighting the customer is the ultimate outcome you would like to accomplish. A multirepo approach is a poor choice as it is geared towards incentivizing behavior that is in the best interest of the project/team but not necessarily the customer. The fallout of such an approach is that it diverts the goal of individuals and teams from customer to features.

To make matters worse the developers working on each of these repositories start to create branches and work on them further increasing the distance of developers between themselves and the overall company goals. Frank Compagner aptly captured this with "Branches create distance between developers and we do not want that". Frank’s ‘distance’ is about the distance to the integration of code from multiple components/modules/sub-teams for a binary that could be deployed or shipped. The problematic distance is to code not yet in the single shared branch, that might:

• break something unexpected once merged
• be difficult to merge in.
• not show that work was duplicated until it is merged
• not show problems of incompatibility/undesirability that does not
• break the build

   "Branches create distance between developers and we do not want that"

As founders or engineering leaders our goal should be to promote practices that reduce the distance between developers and reduce the distance between developers and company goals. Trunk based development is an approach that addresses the problem of reducing the distance between developers and code. In fact trunk based development is a required practice for Continuous Integration. If your are not doing TBD, you are not doing continuous integration right.

If I may take the liberty and extend Frank's thought I would say that "Multirepo create distance between developers and company goals and we do not want that". If you are a customer obsessed company and want to build great product not just features, Monorepo and Trunk based development are key to cultivating customer centricity in your teams.

"Multirepo create distance between developers and company goals and we do not want that"

So is Monorepo and TBD the silver bullet to building great products? I would say generally yes but then lets stop looking for the right answer and instead focus on asking the right questions. This is where I would like to take us back to the initial Heideggarian thought, each one of us are embedded into a world and hence our experience consist of engagement with the world. The truth might be different and the only way to reach there is by "asking the right questions".

References

Trunk Based Development
Being and Time
Hitchhikers Guide to Galaxy