Google Is 2B Lines of Code, All in One Place
171–180 of 347 posts
Re: Google Is 2B Lines of Code, All in One Place
#172I'm a google software engineer and it's nice to see this public article about our software control system. I think it has plusses and minuses, but one thing I'll say is that when you're in the coding flow, working on a single code base with thousands of engineers can be an intensely awesome experience. Part of my job- although it's not listed as a responsibility- is updating a few key scientific python packages. When…
Re: Google Is 2B Lines of Code, All in One Place
#173Just because people are talking about it: I work at MSFT, and the numbers Wired quotes for the lines of code in Windows are not even close to being correct. Not even in the same order of magnitude. Their source claims that Windows XP has ~45 million lines of code. But that was 14 years ago. The last time Windows was even in the same order of magnitude as 50 million LOC was in the Windows Vista timeframe. EDIT: And, r…
Re: Google Is 2B Lines of Code, All in One Place
#174I will say that I saw and experienced many things that changed my definition of 'large' at Google, but the most amazing was the source code control / code review / build system that kept it all together. The bad news was that it allowed people to say "I've just changed the API to to support the initiative, code released after this commit will need to be updated." and have that effect hundreds of projects, but at the…
Can you (or somebody) explain how that works in practice? Here I am ready to deploy some new feature to gmail. In the meantime, I'm getting a steady stream of API changes. Can I build and release gmail to a specific revision number, and only incorporate the changes when I am ready, or are all release essentially off of the tip of the tree. I don't need specifics, just the general idea. Where we work basically every p…
Re: Google Is 2B Lines of Code, All in One Place
#175Earlier quoted context omitted.
The solution to the excessive API change problem is to force whoever changes the API to fix all the consumers himself before the change is accepted. The Linux kernel generally uses this policy for internal APIs for example.
> The solution to the excessive API change problem is to force > whoever changes the API to fix all the consumers himself > before the change is accepted. This doesn't seem scalable. Let's consider the case of one api endpoint being changed by one developer, to add a new param to a function call. Further assume that this impacts hundreds of projects. Does it really make sense to make one developer update those hundre…
Not that it's a silver bullet, but it can make a lot of these cases non-issues.
Re: Google Is 2B Lines of Code, All in One Place
#176(15 million lines of code changed a week) / (25,000 engineers) = 600 LOC per engineer per week
Is ~120 LOC per engineer per workday normal at other companies?
Re: Google Is 2B Lines of Code, All in One Place
#177Earlier quoted context omitted.
That's the same as saying "the same order of magnitude"
But while "1" and "9" are the same order of magnitude, so are "1" and "0.1". To say something is within an order of magnitude of netflix, you cover a possible range from 0.1 to 10 times the Netflix catalog, a range which is ten times bigger if you consider the minimum and maximum sizes...
Re: Google Is 2B Lines of Code, All in One Place
#178Earlier quoted context omitted.
The solution to the excessive API change problem is to force whoever changes the API to fix all the consumers himself before the change is accepted. The Linux kernel generally uses this policy for internal APIs for example.
> The solution to the excessive API change problem is to force > whoever changes the API to fix all the consumers himself > before the change is accepted. This doesn't seem scalable. Let's consider the case of one api endpoint being changed by one developer, to add a new param to a function call. Further assume that this impacts hundreds of projects. Does it really make sense to make one developer update those hundre…
Re: Google Is 2B Lines of Code, All in One Place
#179Earlier quoted context omitted.
That's why Google is so unsuccessful at scaling technical solutions, unlike you they're not forward-thinking.
No, it’s not that they are unsuccessful, it’s that they are unable to maintain it properly. Already today they have tons of open security issues. Or think about April 1st, when they set a Access-Control-Location: * header on google.com because someone wrote the com.google easteregg. Read the post from the SoundCloud dude from yesterday to find out how to do software management properly (hint: modularization is everyt…
Re: Google Is 2B Lines of Code, All in One Place
#180I'm a google software engineer and it's nice to see this public article about our software control system. I think it has plusses and minuses, but one thing I'll say is that when you're in the coding flow, working on a single code base with thousands of engineers can be an intensely awesome experience. Part of my job- although it's not listed as a responsibility- is updating a few key scientific python packages. When…
Could you tell something about the level of documentation? For instance, do you have to write a paragraph of documentation for every function that you add to the system? How about adding preconditions and postconditions, and other invariants? Also, is the code that you add to the repository always inspected by other people? Is that done systematically?