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

51–60 of 319 posts

Re: Software Engineering at Google (2017)

#51

Post by walshemj »

codeflo wrote: post #16
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 th…

I saw this a BT where on system was rewritten in OWS (Oracle Web Services) used 15 Person Years and around a Million Quid - Not the best use of shareholders money.

But some one got to tick some boxes on there promotion track

Re: Software Engineering at Google (2017)

#52

Post by paganel »

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.

> team can probably afford to rewrite most of their software periodically

I think Google partially does this in order to keep its engineers happy, as you are more happy when you develop something from the ground-up compared to just maintaining something already built. By going down this route those engineers are kept in a “happy state” so there’s less risk of them flying off to other pastures, where they could potentially build the next product that could “kill” Google. Sort of invisible golden hand-cuffs, if you will. I personally find it tremendously wasteful at a societal level but I can see the value of this strategy for Google as a company.

Re: Software Engineering at Google (2017)

#53

Post by MichaelMoser123 »

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 am wondering if the rewriting rule applies to AdWords and search, I mean they probably would get very upset if their cashcow stops working, all of a sudden.

Re: Software Engineering at Google (2017)

#54

Post by thetechlead »

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 have time to do so (if they do their work load is not full, increase the load). The 1% I guarantee all your codebase has just been stolen by an ex-employee with malicious attempt. Instead divide your codebase into different projects/roles and people only gain access when needed.

* Software engineers at Google are strongly encouraged to program in one of five officially-approved programming languages at Google: C++, Java, Python, Go, or JavaScript.

We use Go for backend programing and vue (javascript) for frontend. Don't use Java if possible, keep away from C++ and definitely never Python which is a maintenance nightmare.

* The next step is to usually roll out to one or more “canary” servers that are processing a subset of the live production traffic.

Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage.

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

Same as above. Just build and RTFO.

Re: Software Engineering at Google (2017)

#55

Post by hknd »

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 on each other, without being commited.

This might be an interesting read for you: https://paulhammant.com/2014/01/08/googles-vs-facebooks-trun...

Re: Software Engineering at Google (2017)

#56

Post by heavenlyblue »

walshemj wrote: post #51
codeflo wrote: post #16

Earlier quoted context omitted.

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

I saw this a BT where on system was rewritten in OWS (Oracle Web Services) used 15 Person Years and around a Million Quid - Not the best use of shareholders money. But some one got to tick some boxes on there promotion track

Well, but that money was certainly not needed for someone else if it was so readily available.

Re: Software Engineering at Google (2017)

#57

Post by hknd »

MichaelMoser123 wrote: post #53
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 am wondering if the rewriting rule applies to AdWords and search, I mean they probably would get very upset if their cashcow stops working, all of a sudden.

I think we should not take "rewrite" too literally.

But both, search and adwords, have been rewritten multiple times since their launch.

You can have a look at the papers created by Jeff Dean (1) and Sanjay Ghemawat (2) which mention some of the new concepts/technologies/features used in those products.

1: https://ai.google/research/people/jeff 2: https://ai.google/research/people/SanjayGhemawat

Re: Software Engineering at Google (2017)

#58

Post by hoffs »

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…

Why are you comparing stuff that works at big company with a lot of users and stuff that is pretty much required at a company like that, to a startup?

Re: Software Engineering at Google (2017)

#59

Post by jahaja »

weinzierl wrote: post #40
_cs2017_ wrote: post #20

Earlier quoted context omitted.

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?

Branching enables me to share unfinished work with my collaborators. Sometimes I don't want to commit to trunk yet but still share code and collaborate on a part of the code base.

If they're using Perforce one can "Shelve" a CL (changelist, similar to a commit in git) to make it available for others to unshelve. This can be used as a workaround, albeit limited, to share work-in-progress stuff.

Re: Software Engineering at Google (2017)

#60

Post by hknd »

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…

How does it make sense to compare the processes of a company with >100k people touching code and products with more than 1B qps, to a startup with This comparison makes absolutely no sense.
Post reply on HN