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

251–260 of 319 posts

Re: Software Engineering at Google (2017)

#251

Post by dilyevsky »

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.

Google havent been using p4 since around 2013

Re: Software Engineering at Google (2017)

#253

Post by HillaryBriss »

alexandercrohde wrote: post #172

>>Most software at Google gets rewritten every few years. >> This may seem incredibly costly. Indeed, it does consume a large fraction of Google’s resources. However, it also has some crucial benefits that are key to Google’s agility and long-term success. Uh... No? Chrome, gmail, search, youtube, analytics, android, documents all usually have 2 or 3% functionality changes each year. What a ludicrous proposition stat…

Android SDK's job scheduling APIs have been rewritten a lot over the last 5 or 6 years. one gets the impression that they just can't get it right.

Re: Software Engineering at Google (2017)

#254

Post by cpeterso »

I'm curious to learn more about Google's approach to project planning and management, beyond OKRs for personal or team goals.

Do all teams use the same standard process or are teams allowed to do their own thing? What tools and cadence do they use to track project milestones and progress? With Google's monorepo and a centralized bug tracker, they could make some nice project dashboards.

Re: Software Engineering at Google (2017)

#255

Post by stcredzero »

sytelus wrote: post #91
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”."

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…

If you have engineers with psychological problem of “not invented here”, you have a very serious issue.

We need to be precise about what the problem is, exactly. Here is a more salient formulation: "Not Invented Here" is a form of bias that distorts cost/benefit analysis when people are deciding whether to reuse existing code.

They get ticked off by one imperfection here and other over there and immediately run for exit shouting “I could do so much better”.

Given the formulation of NIH as a form of bias that distorts cost/benefit analysis, what can we do at this point? How about quantifying the cost of the "one imperfection here and other over there" instead of going by the subjective being "ticked off?"

Instead of understanding why things are the way it is, they fantasize about how they can one up original authors and claim their own hero title. They go on to throughly underestimate the time to recreate what has taken years of learning.

To complete the cost/benefit analysis, we can then quantify the development cost of the library they are considering re-implementing.

Meanwhile competition has moved on to V2 laughing their way to the bank and customers scratch their heads why you are still stuck in same place for so long. Then our new “owners” gets their promos after massive marketing of how much better everything is now.

This needs to be quantified and put into the cost/benefit analysis.

But to everyone’s surprise they soon leave the project because working on bugs and incremental features has became boring and BTW, the new stuff is just as complex as old stuff. New devs roll in and we start the whole cycle again.

This also needs to be quantified and put into the cost/benefit analysis. Instead of doing cost/benefit analysis attached to individuals, it should be done by product or by project, so that these turnover costs are also accounted for.

Re: Software Engineering at Google (2017)

#256

Post by mlthoughts2018 »

idontpost wrote: post #248
mlthoughts2018 wrote: post #224

Earlier quoted context omitted.

I think the problem is more just a reversal of perspective. It’s up to each different app to detect and respond to a breaking change from a dependency. The idea of wanting to make a change to a third party library and then see all the downstream consumers who would be broken by that change if they updated to start consuming that change is an incredibly stupid thing to want, and it’s no measure of success whatsoever t…

I agree in principle, but in practice its important to remember that your package only exists to be consumed by its dependencies. That is its sole purpose. If your changes aren't serving those consumers, then they're the wrong changes. It's also useful information in the edge case where consumers are relying on undocumented or unintentional behavior in your package. Yes, you don't want a hard-constraint of no-breakin…

When you say,

> “in practice its important to remember that your package only exists to be consumed by its dependencies. That is its sole purpose. If your changes aren't serving those consumers, then they're the wrong changes.”

I agree completely and that’s exactly why you want downstream consumers to opt-in to your changes.

As the library writer / maintainer, nobody knows better than you how to implement the behaviors downstream consumers want. Sure, those other folks know what they want, but are not at all a trustworthy signal for how to solve it for them.

If you are constrained by what breakages your new approach would introduce, this is backwards, exactly from the “in practice” perspective you described. That means you are not able to actually solve your consumers’ problems, create new solutions, refactor old bad ways of working, because you are coupling the what with the how.

The fact that you are beholden to your consumers is all the more reason to decouple the development process from the delivery process. It only makes this idea of wanting a big oracle to tell you what would be broken not because of functional incorrectness but because of a consumers lack of accommodating the new changes all the more egregious.

Re: Software Engineering at Google (2017)

#257

Post by sigsergv »

dilyevsky wrote: post #251
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.

Google havent been using p4 since around 2013

Piper interface and workflow is heavily influenced by perforce.

Re: Software Engineering at Google (2017)

#258

Post by d_burfoot »

I opened this document expecting to have my mind expanded by learning about amazing new techniques for high-level software engineering. I was disappointed. A lot of it just seems to be about release engineering. Yeah, sure, release engineering is really hard and important for a company like Google, but it's of limited general interest. I was particularly disappointed by Google's indifference to the use of smarter languages than the Big 5 (C++, Java, Python, etc).

As an example of something that did expand my repertoire as a software engineer, check out this article by Jane Street: https://blog.janestreet.com/testing-with-expectations/

Re: Software Engineering at Google (2017)

#259

Post by joshuamorton »

dekhn wrote: post #230
Teknoman117 wrote: post #195

Earlier quoted context omitted.

Are you allowed to share if the internal repository a custom version control system or is it one of the open source ones?

it's already been published. Google used Perforce for at least a decade and then cloned the perforce wire protocol when it was clear perforce wouldn't keep scaling (there's a great presentation online about google using RAMSANs to store the perforce index), but backed the repo in something like bigtable or spanner. I'll give google credit for one thing: it can change backends a lot without too much user visible pain.

>I'll give google credit for one thing: it can change backends a lot without too much user visible pain.

Amusingly, this comment may explain how someone in this thread can be incredulous about the idea that things get rewritten every 2-3 years (which yes is an exaggeration).

Google is very good at making sweeping infrastructural changes (generally improvements, I might add) without significant user pain.

Re: Software Engineering at Google (2017)

#260

Post by idontpost »

izacus wrote: post #199
fouronnes3 wrote: post #112

Earlier quoted context omitted.

So basically it's a branch?

Think of a CL like a Pull Request that has (and can only have) a single commit. It's visible in code review UI, has a description, has tests run on it, it can be merged by other people and it can be referenced from anywhere. Eventually it's merged into the head or dropped.

So this is identical to squashing and rebasing your feature branch?
Post reply on HN