Software Engineering at Google (2017) • Hacker News Board

Re: Software Engineering at Google (2017)

#11

Post by weinzierl » Fri, Jan 04, 2019, 10:50 AM UTC

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 Levenberg there is the statement that:

"Development on branches is unusual and not well supported at Google, though branches are typically used for releases."

I my world when we have to make a bigger change we create a branch and only merge it into the trunk when it is good enough to be integrated. The branch enables us to work on that change together. I don't understand how they do this at google. As far as I understand in their model they either have to

- give up on collaboration and always have just a single developer work on a change.

- share code by other means.

- check in unfinished work to the trunk for collaboration and constantly break trunk.

[1] https://youtu.be/W71BTkUbdqE?t=904

[2] https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

Re: Software Engineering at Google (2017)

#12

Post by mateuszf » Fri, Jan 04, 2019, 10:52 AM UTC

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 don't have to check in unfinished work, you can break your work in parts and make people work on independent parts, every one of which moves progress forward incrementally.

Well, you could actually call that "unfinished" because in the beginning the code doesn't accomplish the task, but progressively it will become more useful.

Re: Software Engineering at Google (2017)

#13

Post by aquadrop » Fri, Jan 04, 2019, 10:54 AM UTC

Izmaki wrote: post #4

MeteorMarc wrote: post #2

"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?

We do this at a smaller scale (~1500 employees) with success. It enables everyone to work towards a goal and to discuss with their superior any issues that get in the way, as well as every success story along the way. Both are very important parts of the journey.

What goals/steps are there? Is it anything more than something like

Goal: get promoted/get higher salary

Steps to the goal: did my job well

?

Re: Software Engineering at Google (2017)

#14

Post by blub » Fri, Jan 04, 2019, 10:54 AM UTC

yakshaving_jgt wrote: post #8

Radim wrote: post #5

Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership": "In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."

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.

Any company that can rely on an ads cash cow and a large, competent engineering team can probably afford to rewrite most of their software periodically. This won't apply to most companies, hence the conventional wisdom.

Re: Software Engineering at Google (2017)

#15

Post by taivokasper » Fri, Jan 04, 2019, 10:56 AM UTC

Izmaki wrote: post #4

MeteorMarc wrote: post #2

"Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals" This seems attractive for other large organizations. Any positive or negative experiences from readers?

We do this at a smaller scale (~1500 employees) with success. It enables everyone to work towards a goal and to discuss with their superior any issues that get in the way, as well as every success story along the way. Both are very important parts of the journey.

Could you bring a any examples of individual goals? How are they worded for devs and how different they are from the product goals?

Re: Software Engineering at Google (2017)

#16

Post by codeflo » Fri, Jan 04, 2019, 10:57 AM UTC

Radim wrote: post #5

Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership": "In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”."

I’m not convinced this works so great for Google. Some rewrites are very noticeable as a user, and things in the UI frequently shift around for no discernible reason. Perhaps worse, they seem unable to get below a certain level of bugginess in products like Google Maps and Gmail. Perhaps because a new round of rewrites always introduces new bugs before all of the old ones ever get fixed.

Perhaps their metrics tell them that all of this is fine, I don’t know. But then, you have to realize Google has so much money they don’t really have to spend it very efficiently. For everyone else, this approach to rewrites seems like an extremely expensive way to produce software that’s not even all that great.

Re: Software Engineering at Google (2017)

#17

Post by jsty » Fri, Jan 04, 2019, 11:02 AM UTC

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 could also gate experimental code behind feature flags which aren't set in prod

Re: Software Engineering at Google (2017)

#18

Post by sigsergv » Fri, Jan 04, 2019, 11:03 AM UTC

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…

I think they don't branch code because perforce branches are horrible and merging them back to HEAD is extremely painful process for monorep.

Re: Software Engineering at Google (2017)

#19

Post by yakshaving_jgt » Fri, Jan 04, 2019, 11:10 AM UTC

blub wrote: post #14

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.

Any company that can rely on an ads cash cow and a large, competent engineering team can probably afford to rewrite most of their software periodically. This won't apply to most companies, hence the conventional wisdom.

Like most things, it depends. There are happy mediums between rewriting absolutely everything and making the fewest possible changes. This is true and viable in organisations of any size.

Re: Software Engineering at Google (2017)

#20

Post by _cs2017_ » Fri, Jan 04, 2019, 11:11 AM UTC

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…

Can you clarify why branching helps collaboration? In other words, why is it harder to commit to trunk when you have several developers working on a feature?