Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering at Google (2017)

arxiv.org

Post reply on HN
Print view View original

231–240 of 319 posts

Re: Software Engineering at Google (2017)

#231

Post by yakshaving_jgt »

Aeolun wrote: post #222
yakshaving_jgt wrote: post #8

Earlier quoted context omitted.

Thanks for highlighting this. To me it seems an important idea that contradicts conventional wisdom, similar in the way that most people over-encourage DRY, blind to the fact it increases coupling.

Wait, huh? How does DRY increase coupling? I mean, I guess the duplicate code/class is now coupled to the two places that use it, but I have a hard time seeing how that is worse than two duplicate instances of the code.

It increases coupling in exactly the way you just described.

Sometimes this is beneficial. Sometimes it isn't.

My point is — more often than not — conventional wisdom is that DRY is always preferable, whereas the reality is not that simple.

Re: Software Engineering at Google (2017)

#232

Post by elfakyn »

thetechlead wrote: post #54

I used to be proud of many things in the article when working at the G. Not anymore. Let me talk startup anti-Google pattern here. * Most of Google’s code is stored in a single unified source-code repository, and is accessible to all software engineers at Google This can be the worst nightmare from a management POV in a startup. Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't h…

> * All changes to the main source code repository MUST be reviewed by at least one other engineer.

> Same as above. Just build and RTFO.

Deploying without review is not only a development nightmare (if you keep deploying without review, you'll eventually break something or introduce security vulnerabilities, unstable code etc.), but it can also get you in massive trouble with your compliance audits.

Peer review is very important in production code.

Re: Software Engineering at Google (2017)

#234

Post by BeetleB »

Aeolun wrote: post #222
yakshaving_jgt wrote: post #8

Earlier quoted context omitted.

Thanks for highlighting this. To me it seems an important idea that contradicts conventional wisdom, similar in the way that most people over-encourage DRY, blind to the fact it increases coupling.

Wait, huh? How does DRY increase coupling? I mean, I guess the duplicate code/class is now coupled to the two places that use it, but I have a hard time seeing how that is worse than two duplicate instances of the code.

Here is what I've seen (and been guilty of):

Two pieces of code in different parts of the codebase are very similar. They have nothing to do with each other - even semantically. But the code is very similar. So someone thinks this is code duplication and creates a function/class/whatever that both pieces of code can use. Repeat all over the place.

Then one day, one of those two places needs custom behavior. I can either change that function/class and create complexity (have to now support two use cases). Or I can stop using that function/class in that place and go back to the old solution. Sometimes, this is quite a lot of work as aggressive "DRY" leads to a fair amount of coupling - there could be a few layers of DRY'd code there to untangle.

I put "DRY" in quotes because none of this really is DRY. DRY originally was about requirements - not code. No requirement should show up in multiple places in the code base. In this example, even though the code was almost identical in both places, there was little else common. They dealt with different requirements, for completely different reasons. They should never have been refactored to use a common function/class.

These days people keep talking about over-use of DRY, but they're really complaining about overabstraction of disparate code - not the DRY in the requirements sense.

Re: Software Engineering at Google (2017)

#235

Post by closeparen »

klodolph wrote: post #143
sytelus wrote: post #91

Earlier quoted context omitted.

If you have engineers with physiological problem of “not invented here”, you have a very serious issue. I am currently seeing this in real time in one of the projects and I was told almost exact same words as “reason” to recreate what we already have and working beautifully. It was clear to me that some developers are just too lazy to dive in to complex system. They get ticked off by one imperfection here and other o…

You can call it a psychological problem if you want but calling names is not a solution, nor does it really provide a good path to finding a solution. The labor market being what it is, people will leave steady jobs with good pay for more exciting work with riskier prospects and less pay. This happens all the time. Bug fixes and incremental features will generally not get you promoted for good reasons, we expect seni…

The fundamental nature of a tech company is near-unlimited appetite for new stuff to build and new people to build it. If there are zero projects on your backlog, such that the only way to do interesting work is to retrace old projects, you’re in serious trouble.

Re: Software Engineering at Google (2017)

#236

Post by jkaplowitz »

pjc50 wrote: post #200
shereadsthenews wrote: post #177

Earlier quoted context omitted.

People who like multirepos are always saying how easy it is to pin dependencies but like you I haven’t seen anyone doing it right since I left Google. The monorepo third-party system works well in practice. Ps thanks for getting scipy into third_party all those years ago.

> The monorepo third-party system works well in practice. It's worth noting that this is only viable at Google because they don't use git. Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive. I see conflicting reports over whether google use Perforce or something proprietary called "piper"?

They used to use Perforce and then actually outgrew it (!), implementing an initially backwards-compatible backend called Piper.

(It may still be backwards-compatible, but it's been years since they turned off the last real Perforce and I haven't worked there for years myself. So it may have diverged.)

Re: Software Engineering at Google (2017)

#237

Post by jogjayr »

bsvalley wrote: post #174
hknd wrote: post #168

Earlier quoted context omitted.

I think it attracts a lot of great engineers that they can (mostly) work on something which is used by billions of users. You can basically improve the life of 1B ppl by writing code. Also: having a FAANG company in your CV makes it super easy join any other tech company.

Reality is that most of the engineers at Google don't work on google search nor google map. They work on "smaller" projects that don't necessarily reach billions of users. It doesn't change the fact that everything has to be engineered in order to work for a large amount of users, true, but do you really get that reach? nope unless you're in a very hot and selective team at G. Also, your statement is valid for compan…

Google has 7 products with 1+ billion users.[1]

1. https://www.popsci.com/google-has-7-products-with-1-billion-...

Re: Software Engineering at Google (2017)

#238

Post by mcguire »

hknd wrote: post #55
weinzierl wrote: post #11

What I don't understand is how they accomplish larger collaborative changes. The paper says: "Almost all development occurs at the 'head' of the repository, not on branches." Googler Rachel Potvin made an even stronger statement in her presentation about "The Motivation for a Monolithic Codebase" [1]: "Branching for development at Google is exceedingly rare [..]" In the related ACM paper she published with Josh Leven…

You'll have to remember that all of those big companies have their tools and processes customized for their scale. Example: Instead of branching you would just create a `changelist` (a commit, a set of changes to files) and work on that. You can show it to your colleagues. You can build and test it. You can send the id to anyone to have a look at it, or test it themselves. You can have multiple changelists depending…

"Google use Perforce for their trunk (with additional tooling), and many (but not all) developers use Git on their local workstation to gain local-branching with an inhouse developed bridge for interop with Perforce.

"Branches & Merge Pain

"TL;DR: the same

"They don’t have merge pain, because as a rule developers are not merging to/from branches. At least up to the central repo’s server they are not. On workstations, developers may be merging to/from local branches, and rebasing when the push something that’s “done” back to the central repo.

"Release engineers might cherry-pick defect fixes from time to time, but regular developers are not merging (you should not count to-working-copy merges)"

Re: Software Engineering at Google (2017)

#239

Post by luckydata »

thetechlead wrote: post #54

I used to be proud of many things in the article when working at the G. Not anymore. Let me talk startup anti-Google pattern here. * Most of Google’s code is stored in a single unified source-code repository, and is accessible to all software engineers at Google This can be the worst nightmare from a management POV in a startup. Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't h…

I would like to know more about your reasons for thinking Python is a maintenance nightmare.

Re: Software Engineering at Google (2017)

#240

Post by nradov »

tieze wrote: post #44
weinzierl wrote: post #11

What I don't understand is how they accomplish larger collaborative changes. The paper says: "Almost all development occurs at the 'head' of the repository, not on branches." Googler Rachel Potvin made an even stronger statement in her presentation about "The Motivation for a Monolithic Codebase" [1]: "Branching for development at Google is exceedingly rare [..]" In the related ACM paper she published with Josh Leven…

It might be a practical thing. I've heard from a Googler (a couple of years back) that getting changes in can take ages, and by the time the change lands, there's a good chance that there are merge conflicts, and the cycle starts over. Branches would make this even more painful.

Branches actually make this much less painful. Just reverse merge from the trunk back to each branch on a frequent basis.
Post reply on HN