> That's 20 times almost the size of my, how, how do you even build that? How long to build? Oh, 17 minutes for a new build. That's, that's not bad. We should probably make that better, but that’s not bad.
Am I spoiled for thinking 17 minutes is too much, even if it's 2 million LOC? I guess LinkedIn can afford it
It depends on what those LOC are. Is it HTML? Is it JS? It it a compiled language? How much of it is generated?
Aside: I don't understand the obsession people have with throwing out LOC. It's a completely meaningless number unless you're familiar with the codebase, in which case you don't need to be told the stats.
> Aside: I don't understand the obsession people have with throwing out LOC.
Agreed. A better metric is how much of it you need to interact with on a daily basis in order to perform any meaningful work.
If the code is sane, you'd only ever need to interact with and understand a fraction (a subset of the public APIs) of the entire codebase. You could have millions of lines of code and be productive when knowing only a couple of hundred of those.
If the code is insane, the risk is that you'd need to interact with most of it when introducing any non-trivial functionality. Worst case scenario there isn't any clear rules of what is public and supposed to be used, and what is private and isn't supposed to be used, and people have used "whatever from where ever" to solve their problems.
The second one is always bad, but also significantly worse the more lines of code there are. Perhaps those who throw LOCs around also implicitly tell us that they are dealing with the second variety of code.
It is not too much or too little. The real question is whether the value of X% speedup worth Y hours of developer time to make the improvement. Relative to other work that could be done.
Answer could well be yes since build time impacts everyone, but also have to factor in complexity of the CI system they use.
So reducing this would be a multi-year project of a sizeable team (let's say 5-10 people). How do you get someone to sign off for this kind of expediture and not lay everyone off when the next economic fart comes?
Because THAT'S the hard problem to solve in any bigger organization. Not hacking the code.
>So reducing this would be a multi-year project of a sizeable team
Maybe, or just a knowledgable person to dig in for a bit and solve it. On one of my teams when I was back at Microsoft was working on a similarly huge codebase with build times twice as long. We had a senior engineer who was really into build optimizations from a previous job who wrote a tech design, implemented better project splitting in our monorepo, better local caching, and finally cloud caching, all within 3 months. When I left, our builds ranged from 30 seconds to 3 minutes.
It's not guaranteed that it'll be this simple, but I also don't think it's guaranteed it'll be 3 years and several people.
To clarify: when I say value I don't just mean monetary value - though of course everything in a business ultimately does boil down to that, including the total expectation of risks.
The more important number for a codebase that size is almost always "what's the incremental build time for whatever I work on". It's nice to have a "build from scratch" be fast, but almost always you can leave it for two hours to do the first build while you're in a meeting or something. More important is that when you make a change, the incremental build is fast.
This is why build systems like buck/pants/bazel are good in larger codebases. You can trust your incremental builds in a way that you can't in any build system that isn't hermetic.
Yeah, they could definitely optimize it quite a lot further. With investment in code structure and caching I bet they could get below 5min at that scale. But also for edit/refresh that should be on the order of a second or two, never minutes.
Am I spoiled for thinking 17 minutes is too much, even if it's 2 million LOC? I guess LinkedIn can afford it