3 ms·

Monorepo/multirepo (and monolith/microservice which often tags along) seems like a false dichotomy. There are costs to having big repositories (e.g. TFA and ne

Monorepo/multirepo (and monolith/microservice which often tags along) seems like a false dichotomy. There are costs to having big repositories (e.g. TFA and needing to do scaling work), and there are costs to having lots of repositories involved in producing a unified working result (dependency resolution is NP-complete in many of its useful formulations). Big players have the muscle to optimize Mercurial and Git, so they get to do super slick trunk-only monorepo development at engineer-commit scale, but still often have auxiliary repositories that take e.g. machine generated commits. Smaller players probably aren’t hitting scaling limits on these tools. But every situation is different and if one approaches it as an engineering problem you can usually do something very workable. Likewise with monolith/microservice: there is a happy medium where you introduce a network boundary for an engineering reason (maybe one part of my computation needs a lot of CPU but a different part needs a lot of RAM, so they run on different SKUs/instance types). My big giant web app that dates to the founding of the company? Probably don’t want to rewrite that so let’s spin services out of it incrementally when I need to write something in C++ or use a shitload of RAM or whatever. That’s bread and butter systems engineering. But this “pick a side” mentality where it’s like one giant ball of PHP in one giant Subversion repository or every team has their own little service in their own little repo and I burn 40% of my cycles parsing JSON isn’t a set cover: you’re allowed to choose a happy medium. Just do things for valid technical reasons and don’t have Conway’s law go apeshit on your architecture by shattering it into a zillion pieces. The human factor stuff can be addressed with engineering rigor and consensus. “This is too slow to be in Python now” is a good reason to make a service. “The iOS team shares no code with the web team and bisects will be faster/easier” is a good reason to make a repo. “I want to have my own coding style and/or use some language no one else knows and/or learn k8s and/or not deal with that team I don’t like” are not engineering reasons to type ‘git init’ or make a network call.

afarrell 6y ago
> The human factor stuff can be addressed with engineering rigor and consensus. How do you add engineering rigor and consensus? Let's say as an Individual Contributor.
- cjfd 6y ago
  By working at a place where people listen to you and are not (too) crazy.
  - Cthulhu_ 6y ago
    Just you? If it's a team effort, places like Dropbox have hundreds, if not thousands of engineers, all with an Opinion.
    - cjfd 6y ago
      Sometimes I get they feeling that they should indeed just listen to me. When one needs an argument to convince a colleague that one really should not be using == to compare two floats because of rounding errors or when working in a place currently suffering from blatently ignoring https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... and experiencing the predictable consequences afterwards I indeed quite often get the feeling that in many places where I could work I actually am the only adult in the room. To be a bit more practical, though, yes one should listen to others as well because in some cases they might actually have ideas that are good. Also, morally, it kind of is the golden rule that if one expects to be listened to one needs to listen oneself as well. In cases of large places with lots of people I would say that there should be some form of code ownership and hence people and/or smallish teams can decide what to do with the code that they own. One of the most important things that contributes to code quality is not too many changes of code stewardship.
  - afarrell 6y ago
    Sorry, let me clarify: Given a particular company, how do you add engineering rigor and consensus? Because that was the proposal in contrast to splitting off a separate service.
jazzkingrt 6y ago
I think that's right, but organizationally challenging to implement. In my experience engineers don't really think through this question carefully, and have to be prodded to do the right thing, or at least the thing that better serves others or their future selves. There's also a hump to get over until network effects take over, where engineers have strong incentives to participate in the monorepo. In your iOS vs web team example, we might imagine that they eventually want to run an integration test against the same API, whose team helpfully provides a hermetic version of the service for testing against. (Dropbox wrote some bazel rules for this sort of thing: https://www.youtube.com/watch?v=muvU1DYrY0w https://www.youtube.com/watch?v=muvU1DYrY0w)

afarrell 6y ago

> The human factor stuff can be addressed with engineering rigor and consensus. How do you add engineering rigor and consensus? Let's say as an Individual Contributor.

cjfd 6y ago
By working at a place where people listen to you and are not (too) crazy.
- Cthulhu_ 6y ago
  Just you? If it's a team effort, places like Dropbox have hundreds, if not thousands of engineers, all with an Opinion.
  - cjfd 6y ago
    Sometimes I get they feeling that they should indeed just listen to me. When one needs an argument to convince a colleague that one really should not be using == to compare two floats because of rounding errors or when working in a place currently suffering from blatently ignoring https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... and experiencing the predictable consequences afterwards I indeed quite often get the feeling that in many places where I could work I actually am the only adult in the room. To be a bit more practical, though, yes one should listen to others as well because in some cases they might actually have ideas that are good. Also, morally, it kind of is the golden rule that if one expects to be listened to one needs to listen oneself as well. In cases of large places with lots of people I would say that there should be some form of code ownership and hence people and/or smallish teams can decide what to do with the code that they own. One of the most important things that contributes to code quality is not too many changes of code stewardship.
- afarrell 6y ago
  Sorry, let me clarify: Given a particular company, how do you add engineering rigor and consensus? Because that was the proposal in contrast to splitting off a separate service.

jazzkingrt 6y ago

I think that's right, but organizationally challenging to implement. In my experience engineers don't really think through this question carefully, and have to be prodded to do the right thing, or at least the thing that better serves others or their future selves. There's also a hump to get over until network effects take over, where engineers have strong incentives to participate in the monorepo. In your iOS vs web team example, we might imagine that they eventually want to run an integration test against the same API, whose team helpfully provides a hermetic version of the service for testing against. (Dropbox wrote some bazel rules for this sort of thing: https://www.youtube.com/watch?v=muvU1DYrY0w https://www.youtube.com/watch?v=muvU1DYrY0w)