1. 18
  1.  

  2. 12

    The power of managing changes as single changesets, along with a version control system that understands the entirety of your source, is not to be underestimated. It’s subtle and far reaching. I am persuaded that monorepos are definitely the correct way for a company to roll. Less sure about how that works for individuals or open source systems.

    1. 7

      I’ve used monorepos and “distributed” repos and when monorepos work, they are thing of beauty, especially when it comes to dependencies. They are a lot of work when it comes to tooling (you need people dedicated to it) but it saves a lot of other hassles for devs.

      For personal and open source projects? I’m not so convinced, but not against it.

      1. 5

        Our team briefly jumped on the Github train when it first came out, making small repos for each of our libraries. The amount of time we spent dealing with versioning and broken downstream consumers was staggering. We eventually came to our senses and checked them all in to the main repository and life was so much easier.

      2. 6

        I’m sure it’s all very impressive, but I think ultimately it shows how a large organisation can drift toward throwing a lot of frankly needless investment after an early technological decision. It’s also no wonder they don’t open source much or any existing code.

        1. 9

          I do think that it’s entirely likely that there’s a healthy dollop of path dependence and self-serving bias in Google’s technical decision making; but I think that it’s also fair to point out that there haven’t been many companies of their size with their technical resources before, and that it might well be perfectly rational for them to build their own toolchains. I tend to think that there’s a lot of uncritical acceptance of cargo-cult nonsense in software, and perhaps Google’s decision to strike out on their own was the correct one.

          1. 8

            I think it is unfair to call it needless.

            First, an investment of similar size would have been needed no matter what they chose to do in the early days. Organizing that much code and making it simple for developers to work on it is an insanely complicated task. There is no such thing as an easy path there.

            Second, all the tools they’ve developed greatly improve productivity. Sure there is a large cost up front with tooling, but the rewards are paid back many times over in the long run. Maybe they didn’t need to make all those tools, but it’s sure paying off for them now.

            It would have been nice if they worked more in the open, yes. But they have been starting to do that more and more lately with things like bazel and upstreaming work to mercurial.

            1. 6

              While some amount of tooling and process investment is always required, I’m not convinced that maintaining your own entire parallel universe of tooling in a way that will seemingly never be applicable outside one company is really a good use of resources. It has essentially been an uncontrolled experiment; clearly lots of people in other organisations have made the opposite choice – e.g. smaller, more coherent repositories and tooling that can be shared amongst organisations – and are not failing as a result.

              Chiefly, also, they have now seemingly thrown so many resources at perpetuating this original decision that it might be difficult to justify exploring other options. This was really the core of the point that I’m trying to make: that this decision was drift; each decision to stay on this path was probably relatively small and locally rational at the time.

              1. 7

                For context I work on similar tools at Mozilla. We also use a monorepo (albeit nowhere near as large) and I personally think monorepos are awesome. Though we open source everything we do, most of it is only applicable to our own infrastructure. We’re thrilled when other companies start using our tools, but designing them for external use really really slows down development. I totally understand why Google wouldn’t want to do that.

                But I don’t think your point about drift is valid. It’s not that Google has to do this. They’ve had good enough infrastructure for years and years, yet they still invest that much time and energy because it is a good investment. Same with my team at Mozilla, I could get fired tomorrow and the company would still chug along without me, but Mozilla sees the value in increasing productivity so I have a job.

                A couple more misc points:
                1. Google isn’t failing either
                2. These tools are slowly making their way to the general public, it just takes a lot of time. Google is at the forefront of infrastructure driven development
                3. I suspect this is actually a debate about monorepos vs many small repos

                1. 5

                  clearly lots of people in other organisations have made the opposite choice

                  How many organizations have engineering teams that size?

                  My employer is closer to ~1000 developers - I’ve seen firsthand the nightmare that is deploying security patches to small, coherent repos.

                  1. 4

                    Yeah, this is why it’s an uncontrolled experiment.

                  2. 4

                    The ‘not failing as a result’ thing is a bit of a furphy.

                    For instance:

                    • Automattic are using PHP for everything and not failing as a result.
                    • Microsoft used stack ranking in the past ( thx for the correction)
                    • Oracle are using litigation-driven-development and not failing as a result.
                    • JIRA takes multiple seconds per pageload and requires lots of navigation, but remains widely used.
                    1. 1

                      Microsoft no longer uses stack ranking. If they do, it’s not exposed at all to people in my position.

                    2. 2

                      smaller, more coherent repositories and tooling that can be shared amongst organisations

                      FWIW, they also developed repo that they use for managing their Android source code.

                2. 3

                  Ooh, ooh, I know!

                  Making a massive monorepo work: a scaling problem!

                  Figuring out how to partition a codebase into separately-tracked components that still may depend on each other: an organizational engineering problem!

                  What kinds of problems does Google prefer to solve? Scaling problems!