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

301–310 of 319 posts

Re: Software Engineering at Google (2017)

#301

Post by username90 »

lordnacho wrote: post #27
philosopher1234 wrote: post #24

Earlier quoted context omitted.

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?

They are grouped by linking them to issues in the issue tracker. All commits will then get a link to the issue and the issue gets a link back to the commit. This way you can easily track and read the full context of old changes.

Example issue, note that public ones are not associated with commits: https://issuetracker.google.com/issues/122326181

Re: Software Engineering at Google (2017)

#302

Post by srj »

StreamBright wrote: post #34
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 makes sure there is never 1.0 ever. I think this is one of the biggest mistake in software. We just keep rewriting things that are already doing what they supposed to. Like the Gmail UI. It got rewritten 3 times already and every iteration it gets shittier.

I think you're imagining much larger rewrites.

A system such as Gmail is composed of many smaller parts. If one of those parts was written years prior for a world that has since changed, it may be accruing technical debt as it's continually extended to fit new requirements. An occasional rewrite helps address this type of decay.

Without the rewrite you may find yourself 10 years later with a system that's both critical and kludgy, and at that point the rewrite will be a much larger project.

Re: Software Engineering at Google (2017)

#303

Post by detaro »

alexis_fr wrote: post #294
pacala wrote: post #206

Earlier quoted context omitted.

Pinning dependencies is easy, and gets one stuck on Java 1.3 and IE 6. Since the library maintainer doesn't know it broke dependent code, the dependent code will be unlikely to have a smooth upgrade path. It's just a matter of having the luxury of picking up a time to pay the cost of dependency upgrades. Which cost may be high in a world where your dependencies also pin dependencies, likely at different versions. The…

That’s a good point. Do we have any solution from companies who use git/multirepos for their libraries? Is there anyway to compile refactored libraries against existing code?

For various public package managers, there's tools that automatically send e.g. a GitHub PR for an updated dependency file when a dependency updates, which then is tested by CI. I guess something like that could be made for private repos and test versions of packages too, reporting back to the authors of the dependency.

Re: Software Engineering at Google (2017)

#304

Post by shereadsthenews »

dekhn wrote: post #227
pjc50 wrote: post #200

Earlier quoted context omitted.

> 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"?

I used a git wrapper for google3 repo. It wasn't great. There are a number of semantic differences between piper/perforce and git that made it awkward. Especially code review- git doesn't handle code review well (I still find this to be an issue with github and other sites that have code review). but it was not an officially supported solution and I believe the replacement for it is based on another DVCS, Mercurial,…

I used the git wrapper for a few days until I hit a day-ending `git gc`. That's when I knew git was terrible.

Re: Software Engineering at Google (2017)

#305

Post by joshuamorton »

bsvalley wrote: post #175
yifanl wrote: post #159

Earlier quoted context omitted.

I'm not sure what you could do to improve engineering culture beyond making your office a little bit nicer without starting to take away from life outside the office.

You can innovate in many different areas. For example code reviews, CI/CD pipelines, sharing knowledge across the organization. It seems that Google as a pretty solid engineering culture but it doesn't really innovate much like a lot of other large tech companies. Standards are meant to be broken.

I mean, google was the innovator for many of these practices. They originated Gerrit and no code review tool comes close to critique, although GitHub and co are catching up.

A lot of the innovation (kythe, grok) isn't mentioned here, but is necessary.

Re: Software Engineering at Google (2017)

#306

Post by bsvalley »

jogjayr wrote: post #300
bsvalley wrote: post #247

Earlier quoted context omitted.

Now let's look at the ration billion-user-products versus the total number of products. That'll give you the ration of employees having a huge impact: https://en.wikipedia.org/wiki/List_of_Google_products And we're not even looking at the number of active users per product versus the total amount of gmail ID's enabled for all google products by default (e.g. Google+)

> Now let's look at the ration billion-user-products versus the total number of products. That'll give you the ration of employees having a huge impact That logic doesn't make any sense. No company allocates staff equally to all their products. More popular products (or higher revenue-generating products) are always better-staffed than less popular products.

You can't say "always". This doesn't make sense either because it's on a case by case basis. You could have a simple product used by billions of people, which doesn't require many devs, or you could have a complicated infrastructure no one knows about that gets billions of requests from 10 other products per day. This could be handled by an army of engineers.

Is your hot product in a maintenance mode? If so, just a few devs can handle it.

Then you have companies with groups like retail, legal, hardware, etc. They require tones of software engineers to build internal tools. They definitely don't reach billions of users and you see a lot of these teams. What I found out while working at some of the Faang's is that the hottest teams are usually very lean. You'd be surprised how one single rock star engineer can handle. When you start having +10k engineers in your company, only a minority of folks will end up working on the hot stuff.

Re: Software Engineering at Google (2017)

#307

Post by why_only_15 »

fergus_google wrote: post #182
why_only_15 wrote: post #30

Earlier quoted context omitted.

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.

It's common for code at Google to be rewritten without reusing most of the existing tests -- instead, new tests are written for the new code. Yes, this risks not understanding edge cases. But not all of those edge cases are still important.

Maybe a compromise would be that if you rewrite old code you individually go through old tests and have to sign off on deprecating them, and say edge case X is no longer important, so you keep most tests while not using ones that don't matter.

Re: Software Engineering at Google (2017)

#309

Post by [deleted] »

stillworks wrote: post #217

So, the thing that is still buzzing in my head now and not mentioned in the article (maybe I didn't read carefully enough), what actually gets released into prod after a change is reviewed and merged. If the monorep contains let's say five different products and in a day only one of them gets a merge, then Blaze still builds all five and all five are released (based on successful integration testing)? OR only release…

[deleted]

Re: Software Engineering at Google (2017)

#310

Post by stillworks »

ASinclair wrote: post #243
stillworks wrote: post #217

So, the thing that is still buzzing in my head now and not mentioned in the article (maybe I didn't read carefully enough), what actually gets released into prod after a change is reviewed and merged. If the monorep contains let's say five different products and in a day only one of them gets a merge, then Blaze still builds all five and all five are released (based on successful integration testing)? OR only release…

Like kyrra said. Releases are handled by independently by each team. Teams are in various states of maturity in relation to their release practices. Some are fully automated. Some involve manual QA. I've supported teams across that continuum as a SETI at Google. I'm not as well-versed in canarying though I've set it up for a team or two. I've only ever seen a single canary version for any particular binary. Canarying…

Thanks for all replys above (Kyrra, Joshuamorton and ASinclair), these have been very helpful.
Post reply on HN