Live data from Hacker News

Google Is 2B Lines of Code, All in One Place

wired.com

171–180 of 347 posts

Re: Google Is 2B Lines of Code, All in One Place

#172
post #81

I'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…

If I recoup with latest news: The ranking algorithm is in one repo, Chrome and Android in another, and all the rest is in Piper? What is all the rest? Gmail, Calendar, the defunct Reader, the car, Maps, and OnHub... How does that fit with Alphabet? Is Piper a cross-functional initiative of Alphabet now?

Re: Google Is 2B Lines of Code, All in One Place

#173
post #109

Just 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…

Would you rather work on the linux kernel instead of windows?

Re: Google Is 2B Lines of Code, All in One Place

#174
post #92

I 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…

Every feature has a flag that you can turn on/off to your heart content. Releases are cut at head. No need to use the version control hammer to screw all the zippers.

Re: Google Is 2B Lines of Code, All in One Place

#175
post #22

Earlier 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…

It's scalable with the right tools. If you can write a transform at the level of the AST that will make the change for you, you can do it in one commit. FB has written about this: https://medium.com/@cpojer/effective-javascript-codemods-5a6...

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

#177
post #158
post #134

Earlier 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...

[deleted]

Re: Google Is 2B Lines of Code, All in One Place

#178
post #22

Earlier 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…

Google's product explosions / surprise deprecations possibly hint that this is what happens? Changing the API becomes cumbersome, so you just make a new product with a new API to do an end-run around the requirement...

Re: Google Is 2B Lines of Code, All in One Place

#179
post #36

Earlier 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…

Why don't you list those "tons of open security issues" ?

Re: Google Is 2B Lines of Code, All in One Place

#180
post #81

I'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?

It is mandatory that each code change is inspected for correctness, language style and approved by a code owner (all 3 may be the same person, or require multiple, depending on the situation).
Post reply on HN