Software Engineering at Google (2017) • Hacker News Board

Re: Software Engineering at Google (2017)

#21

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

sigsergv wrote: post #18

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.

So, use a better tool?

Re: Software Engineering at Google (2017)

#22

Post by wahnfrieden » Fri, Jan 04, 2019, 11:17 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…

There’s a wealth of reading available to you if you look up “trunk-based development” as a keyword. Likewise with “continuous integration” (the actual practice, not the build tooling). Jez Humble for instance has written extensively on this.

Re: Software Engineering at Google (2017)

#23

Post by afpx » Fri, Jan 04, 2019, 11:17 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 found this for you:

https://trunkbaseddevelopment.com/

I only scanned through it, but it seems similar to the de facto way of doing things before distributed version control systems became popular (in the late 2000s?).

Re: Software Engineering at Google (2017)

#24

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

raverbashing wrote: post #21

sigsergv wrote: post #18

Earlier quoted context omitted.

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

So, use a better tool?

Or, don’t branch. Is branching so essential?

Re: Software Engineering at Google (2017)

#25

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

jsty wrote: post #17

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

I agree that feature flags can be a solution sometimes. The presentation and the paper I linked to in my question discusses this, but they also mention large-scale refactorings and this is where I don't see how feature flags can help.

For example: How do they untangle a wad of code that is large enough that it takes longer than a few days and more than a single developer to get the code back into a state that is acceptable for trunk?

The changes required for this kind of refactorings can be all over the place, regardless of any organizational boundaries in your code. I can't see how changes of this nature can be put behind feature flags.

Re: Software Engineering at Google (2017)

#26

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

taivokasper wrote: post #15

Izmaki wrote: post #4

Earlier quoted context omitted.

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?

It's not easy to list goals from the top of my head as it's not my strong side, and especially not if they have to be measurable (which good goals should be, rather than your boss evaluating whether or not you did something), but here goes:

Goals could be "Pick up language X in order to help development on project Y" or "Get formally introduced to all R&D team leaders, and get introduced to their roadmaps" or "Facilitate 10 job interviews together with team leaders in marketing"

Re: Software Engineering at Google (2017)

#27

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

philosopher1234 wrote: post #24

raverbashing wrote: post #21

Earlier quoted context omitted.

So, use a better tool?

Or, don’t branch. Is branching so essential?

Isn't it essential for mental organisation? How do you think about what's different about a set of changes without some sort of DAG?

Re: Software Engineering at Google (2017)

#28

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

aquadrop wrote: post #13

Izmaki wrote: post #4

Earlier quoted context omitted.

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 ?

"Did my job well" might be one, but it's hard to measure... otherwise see above :D

Re: Software Engineering at Google (2017)

#29

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

philosopher1234 wrote: post #24

raverbashing wrote: post #21

Earlier quoted context omitted.

So, use a better tool?

Or, don’t branch. Is branching so essential?

If you don't want to be stuck while a colleague does changes that conflict with what you're changing then yes, you need branching.

Re: Software Engineering at Google (2017)

#30

Post by why_only_15 » Fri, Jan 04, 2019, 11:32 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”."

This is interesting to me because something like this only works if there are lots of tests and they can be run after every change. If you rewrite code constantly and potentially create new bugs by e.g. not understanding edge cases previous developers put in, then this isn't feasible. With a focus on testing this becomes practicable.