2 ms·

I think its kind of both. When you have a lot of people working on a monolithic code base one of the places where you feel the most friction is at the build pro

I think its kind of both. When you have a lot of people working on a monolithic code base one of the places where you feel the most friction is at the build process. If CI takes 30 minutes for example and you have 80 developers working on the code base (roughly the stats from my previous job) then you can see how just coordinating the build/merge/rebase/build/merge cycle can be an issue without good tooling and practices. At some point service boundaries are inevitable and shipping the org chart is something we've always done. But what is actually happening in some companies is just so far beyond this. There are developers I've talked to at companies where the micro-services outnumber the developers by 5:1 or more. That is insane, and I imagine it did start with the kind of empire building you are talking about.

m0zg 6y ago
> I think its kind of both. Yes. I'm old enough to see nuance. I do not assert that these are the only causes. I only assert that they are the primary causes most of the time. As a side note, there's something deeply wrong if CI takes 30 minutes. This usually indicates that all tests are re-run every time, which is something you can easily avoid by e.g. using a modern build system such as Bazel, which will only re-run the affected subset of tests when something changes, because it is able to track all changes to the transitive closure, including data. Also 80 people on a team sounds like a nightmare. I don't think I've ever seen a monolithic team this large in my 25 years in the industry, some of which was spent at Microsoft, of all places. The best size is that of a large family - 5-7 engineers. That way communication overhead does not dominate, and you can still do very sophisticated and substantial things. Beyond this magic number the productivity growth is usually negative.

m0zg 6y ago

> I think its kind of both. Yes. I'm old enough to see nuance. I do not assert that these are the only causes. I only assert that they are the primary causes most of the time. As a side note, there's something deeply wrong if CI takes 30 minutes. This usually indicates that all tests are re-run every time, which is something you can easily avoid by e.g. using a modern build system such as Bazel, which will only re-run the affected subset of tests when something changes, because it is able to track all changes to the transitive closure, including data. Also 80 people on a team sounds like a nightmare. I don't think I've ever seen a monolithic team this large in my 25 years in the industry, some of which was spent at Microsoft, of all places. The best size is that of a large family - 5-7 engineers. That way communication overhead does not dominate, and you can still do very sophisticated and substantial things. Beyond this magic number the productivity growth is usually negative.