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

311–319 of 319 posts

Re: Software Engineering at Google (2017)

#311

Post by lugg »

quietbritishjim wrote: post #279
lugg wrote: post #271

Earlier quoted context omitted.

You're talking about rewrites. I'm talking about cleaning up messes left by lazy people long ago, so long ago that most of the juniors are scared to clean it up despite it being impossible to understand without a days reading. You can say it disrupts others understanding of shitty old code, frankly I don't care. Code is not immutable and maintaining status quo helps nobody except the old guard stay relevant.

I said: > Of course, sometimes rewrites/refactors really are an improvement If that's what you were talking about in the first place, fair enough and my apologies.

No apologies needed. It was a fair assumption and I do agree with your points, although I think I've come to move more in the other direction the last few years.

Those perfect one line fixes are great but they approach their limits and eventually need to be refactored. This is natural and should not be frowned upon. Likewise you can't just refactor all the time, one line fixes are faster and less costly in all sorts of ways. The key is to pick and choose when to use each strategy.

I think we're too often looking for simple rules. There are none. Just a bunch of guidelines.

Re: Software Engineering at Google (2017)

#312

Post by thisiszilff »

PurpleBoxDragon wrote: post #132
sytelus wrote: post #116

Earlier quoted context omitted.

There are always good technical reasons to rewrite things but the reason quoted by the parent i.e. devs not “feeling” ownership and won’t work on code wholeheartedly unless it’s their code - those reasons are evil.

Does the developer not work on any systems unless they feel it is theirs, or is it a particular system that causes this phenomena? If it is the latter case, then the dev's reasoning is really a symptom of a deeper problem.

If you feel ownership over some system, you feel as if the whole system reflects on yourself, whereas if you do not feel that sense of ownership, then you feel as if only the work you do on that system reflects on yourself. If you feel ownership then, you're likely to be more proactive in your maintenance and making sure that everything is up to standard rather than being reactive and fixing things that break. You want people to feel a sense of ownership, and rewriting a project is a very good way of doing that. Rewriting may not be the only way, of course, and it may not be the most optimal solution given other goals.

Re: Software Engineering at Google (2017)

#313

Post by radicality »

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've been at FB for a few years now (similar style) and this model of a monolithic repo, no branching, and simply submitting 'difs' (a list of changesets / patches) which get merged directly into master after the 'diff' is accepted and you land it seems much easier to me. Maybe it's just because I got used to it, but now whenever I have to touch it I find the branch-based development confusing.

Re: Software Engineering at Google (2017)

#314

Post by Pokepokalypse »

zozbot123 wrote: post #173
rodorgas wrote: post #171

Earlier quoted context omitted.

It’s not a physiological problem, it’s a technical problem. They do it so they work gets easier. It’s much easier to write code than to read code.

> It’s much easier to write code than to read code. The fact that "write-only code" is apparently considered a part of sensible software-engineering practice speaks volumes about what their technical culture is like more generally. One would think that code should be much easier to read and survey than it was to write.

The whole point of a computer language is so that another human being (or a team of human beings) can read it.

If the intention is for a uniquely skilled human to give a computer instructions, and the computer to execute them - then just write it in machine code.

Re: Software Engineering at Google (2017)

#315

Post by Pokepokalypse »

titzer wrote: post #292
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”."

Disclaimer: I work for Google. I speak only for myself. In my honest opinion, frequent rewrites are by-and-large a disastrously bad idea, for several reasons. If there is one thing I would change about Google, it would be to slow down the frenetic pace of change inside. Rewrites just make the pace of change untenable. And I say this as one who is totally part of the problem: I helped rewrite significant parts of V8,…

dude.

So much 3, 4, and 5.

I was so spoiled at my last employer. Leaving was a mistake, but I can't go back because I relocated. Seems like nobody in this entire town "gets it". Seriously.

Re: Software Engineering at Google (2017)

#316

Post by jazzdev »

seanmcdirmid wrote: post #134
sytelus wrote: post #91

Earlier quoted context omitted.

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…

Code rots, even the best code rots, because the people and cultural environment that the code was written under change and fade away. Refreshing it occasionally, even if it isn’t improved in a significant way, is one way to deal with that rot. Even if the product/library/framework never changed much, rewrites would still be necessary to keep it going as new generations of programmers shuffle through. Otherwise we win…

Code does not rot. It gets complicated and starts to look rotten, but that's the hard won complexity of features and bug fixes. To think you can start over and not re-introduce bugs that have already been fixed seems foolhardy.

Re: Software Engineering at Google (2017)

#318

Post by collinmanderson »

jazzdev wrote: post #316
seanmcdirmid wrote: post #134

Earlier quoted context omitted.

Code rots, even the best code rots, because the people and cultural environment that the code was written under change and fade away. Refreshing it occasionally, even if it isn’t improved in a significant way, is one way to deal with that rot. Even if the product/library/framework never changed much, rewrites would still be necessary to keep it going as new generations of programmers shuffle through. Otherwise we win…

Code does not rot. It gets complicated and starts to look rotten, but that's the hard won complexity of features and bug fixes. To think you can start over and not re-introduce bugs that have already been fixed seems foolhardy.

The underlying dependencies (OS, libraries, runtime, compiler, etc) slowly get out of date.

Out of date dependencies can be seen as code rot, regardless of quality/state of the actual code.

(Not saying that it should be rewritten because of that, but I do consider outdated dependencies to be code rot.)

Re: Software Engineering at Google (2017)

#319

Post by auiya »

sjg007 wrote: post #269
auiya wrote: post #264

Earlier quoted context omitted.

This is simply part of how they've implemented Jack Welch's Vitality Curve[1]. It's pretty common practice for most large companies, although I understand more and more are starting to move away from this approach. As it turns out, most people don't enjoy playing Game of Thrones with their co-workers every quarter. [1] https://en.wikipedia.org/wiki/Vitality_curve

OKRs are straight out of Andy Grove from Intel. If you read further along, the author indicates that getting fired from Google is very rare. So it's not a fire the bottom 10% every year.

Andy and Jack knew each other well. Where do you think Andy's strategy came from? It's the same thing as Jack's Vitality Curve, only without firing the bottom 10%.
Post reply on HN