Live data from Hacker News

Software Engineering at Google

arxiv.org

21–30 of 161 posts

Re: Software Engineering at Google

#21
post #2

They have a billion files in their repo, 9 million are source files. What the heck is the other 991000000? I skimmed this. Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.

> Mostly just stuff any competent company would/should be doing.

Many companies should be doing this. Few (that I know of) are doing this.

Making data-driven decisions also should be a thing, yet many still make them based on nonsense like politics.

Re: Software Engineering at Google

#22
post #2

They have a billion files in their repo, 9 million are source files. What the heck is the other 991000000? I skimmed this. Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.

Well, I just fired up Android Studio and created a blank app. I ended up with no less than 77 files. Seriously, 77 files for a freaking BLANK app.

That "Hello World" Flask program that was 1 nice cute file? It's about 20 files deployed in Heroku.

Sometimes I wonder if things really need to be this complicated.

Re: Software Engineering at Google

#23
post #2

They have a billion files in their repo, 9 million are source files. What the heck is the other 991000000? I skimmed this. Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.

> Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.

Yes, you're absolutely correct. But here's the thing - it was actually Google that pioneered many of this. Many of the big/competent companies that are following these practices are because of Google's "DNA" leaking into those companies (via former employees bringing along the best practices learned at Google, etc.)

Re: Software Engineering at Google

#24
post #21
post #2

They have a billion files in their repo, 9 million are source files. What the heck is the other 991000000? I skimmed this. Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.

> Mostly just stuff any competent company would/should be doing. Many companies should be doing this. Few (that I know of) are doing this. Making data-driven decisions also should be a thing, yet many still make them based on nonsense like politics.

[deleted]

Re: Software Engineering at Google

#25
post #22
post #2

They have a billion files in their repo, 9 million are source files. What the heck is the other 991000000? I skimmed this. Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.

Well, I just fired up Android Studio and created a blank app. I ended up with no less than 77 files. Seriously, 77 files for a freaking BLANK app. That "Hello World" Flask program that was 1 nice cute file? It's about 20 files deployed in Heroku. Sometimes I wonder if things really need to be this complicated.

No, they don't.

Re: Software Engineering at Google

#27
post #21
post #2

They have a billion files in their repo, 9 million are source files. What the heck is the other 991000000? I skimmed this. Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome.

> Mostly just stuff any competent company would/should be doing. Many companies should be doing this. Few (that I know of) are doing this. Making data-driven decisions also should be a thing, yet many still make them based on nonsense like politics.

Right, because data leaves no room for interpretation.

Re: Software Engineering at Google

#29
Is the practice of shoving all disparate pieces of proprietary software (or individual projects) in the same repo a common occurrence? I have found that pulling unrelated changes just so that I can push my changes is an inconvenience. Furthermore, tracking the history of a particular project is confounded due to unrelated commits. I am sure that their vcs (piper?) makes this a feasible task, but for git, it seems like it would suck.

The article posted by kyrra, mentions this.

Given the value gained from the existing tools Google has built and the many advantages of the monolithic codebase structure, it is clear that moving to more and smaller repositories would not make sense for Google's main repository. The alternative of moving to Git or any other DVCS that would require repository splitting is not compelling for Google.

It seems like they have just too much invested in this "shove it in the same repo" style. Or is this the more appropriate way to do things in a large organization?

Re: Software Engineering at Google

#30

Is the practice of shoving all disparate pieces of proprietary software (or individual projects) in the same repo a common occurrence? I have found that pulling unrelated changes just so that I can push my changes is an inconvenience. Furthermore, tracking the history of a particular project is confounded due to unrelated commits. I am sure that their vcs (piper?) makes this a feasible task, but for git, it seems lik…

It actually works quite nicely. Most of the google software is built internally. Ensuring everyone is running at head is a blessing (rarely a curse), because when you make a change you immediately see if it breaks something. You can also be sure everything gets all the bug fixes in their new release. This is good for various reasons, including the fact that it makes security audits significantly simpler.

Some google orgs, like android, don't use the existing infra, and they kind of struggle and have to reinvent most wheels, because of that.

Edit: added second paragraph

Post reply on HN