Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering at Google

arxiv.org

Post reply on HN
Print view View original

151–160 of 161 posts

Re: Software Engineering at Google

#151

Post by milesrout »

arjie wrote: post #57
milesrout wrote: post #49

Earlier quoted context omitted.

No, it's not common. It's something that a couple of big companies have done, and while it might work for them it does NOT work for most people. It's a really, really bad way of doing development.

Why is it so bad? It seems incredibly effective for them and there are very good outcomes: • no trailing dependencies so you never have to backport fixes, maintain multiple released versions, etc. • extensive integration testing of libraries since they go live instantly • forced library developer and library user collaboration • deployed code is not out of date What's the problem with only One True Version? All the c…

Well I suppose my statement was a little strong. The Linux kernel is essentially a monorepo: it contains the kernel and many, many dependent projects (drivers/modules). They do what Google claims to do with their monorepo: change all dependent packages at once if they change an internal API.

Re: Software Engineering at Google

#152

Post by losalamosal »

hueving wrote: post #144
nickpsecurity wrote: post #104

Earlier quoted context omitted.

A clear statement of what you're going to do, some constraints on the design a la Design-by-Contract, and languages/libraries that mitigate errors by design are so easy to do that small shops do them on a regular basis. Ada/SPARK, Eiffel, Ocaml, and Haskell are examples with steady business in industry with last three used on relatively-fast-moving projects. Add in static analysis, spec-based generation of tests, and…

All of the processes you just described are antithetical to the processes I was referring to. Writing URL, design specs, etc is not the same thing is automated test generation, static analysis, and an API contract agreement. The thing you just described is exactly what I'm saying replaces all of the "on paper" crap that was taught as "software engineering" in schools as short as 4 years ago.

Or 40 years ago! I'm no fan of "process", but if you don't at least write down what you're trying to do (requirements) and some metrics for judging success, you open yourself up to two equally troublesome outcomes (depending on who's doing the evaluating): it's all a success or everything's a failure. Well written requirements and metrics (even brief ones) remove some of this evaluation ambiguity.

Re: Software Engineering at Google

#153

Post by technofiend »

delroth wrote: post #116
hueving wrote: post #60

>Engineers are permitted to spend up to 20% of their time working on any project of their choice, without needing approval from their manager or anyone else. From what I understand talking to current employees, this is now bullshit. You could spend 20% on other stuff, but the culture in many of the groups is such that you are putting your peer review at risk by doing so because of your reduced output. Any current Goo…

I spend 10-20% of my time at Google (depending on the needs) developing and maintaining an internal tool that is used by 100-1000 engineers across 10-100 teams (not including my current team). Not only have my last 3 managers been extremely supportive of this, I've netted a few peer bonuses from this, and some nice feedback from senior people that appreciated my work. The "approval from my manager" amounted to tellin…

You've made yourself an integral part of the company and gotten your name out there to boot.

Back when I worked at Compaq there was a tool everyone used in the build process and it had a splash screen that mentioned the author. That guy was a legend at Compaq because everyone had at least heard of him. When my buddy took over the build process he ended up emulating Mr. Legend and put his name on his tool that was used thousands of times a day. Same thing happened to him: oh you're the Mr. Coder? He had his pick of projects for a very long time.

Re: Software Engineering at Google

#155

Post by annnnd »

cookiecaper wrote: post #137
NumberSix wrote: post #89

Google is highly non-representative of businesses and technology businesses in particular. It has a near monopoly on the search business and has enormous amounts of money from a single source -- advertising. Google Fiscal Year 2015 Revenues: $74.54 Billion (source: Google) Advertising Revenue: $67.39 Billion (source: https://www.statista.com/statistics/266249/advertising-reven... ) Profits: $23.4 Billion Market Capit…

>Blindly copying highly expensive software development processes from Google or other super-unicorn companies like Apple or Facebook is likely a prescription for failure. Yes, this can't be stressed enough. Out here with the little people like non-Google-employed me, there's almost a desperation to copy the things that Google and Facebook do, and it's often justified with "Well, Google, Facebook, or Netflix use it!"…

While I agree with the spirit of your post, I think you are taking the argument too far in places. For instance, we are a small team of devs and Docker solved a real problem for us. Our deployment was once on bare OS and it was a nightmare. Different distributions, different library versions (with their own sets of bugs)... Unfortunately we couldn't demand a specific environment from our customers and at the same time it drained our resources trying to accommodate all installation variants. When Docker came out we tried it out, saw that it solves all these issues beautifully and never looked back. But we use it only because it insulates our installation from Linux (apart from the kernel that is), not because it is hip.

More general advice is: take G, A, FB, NF... papers (and HN posts, while we are at it ;) ) with a grain of salt, test before use and make sure it solves more problems than it creates - for you.

Re: Software Engineering at Google

#156

Post by benzewdu »

kyrra wrote: post #82
benzewdu wrote: post #62

Although there is a well-defined process for launch approvals, Google does not have a well-defined process for project approval or cancellation. Despite having been at Google for nearly 10 years, and now having become a manager myself, I still don’t fully understand how such decisions are made. The reason why I quit Google.

The rest of the paragraph you quote is fairly important as it goes on to explain cases and how a project can be cancelled. The rest of the quote: In part this is because the approach to this is not uniform across the company. Managers at every level are responsible and accountable for what projects their teams work on, and exercise their discretion as they see fit. In some cases, this means that such decisions are ma…

The question isn't how, it's why. I wish i could share the details.

Re: Software Engineering at Google

#157

Post by neilparikh »

aioprisan wrote: post #94
hiddencost wrote: post #85

Earlier quoted context omitted.

Companies own your work even if you do it off the clock, in many cases.

That's not the case in most states, like California, New York and Massachusetts, due to state laws.

California excludes IP that:

> Relate at the time of conception or reduction to practice of the invention to the employer’s business, or actual or demonstrably anticipated research or development of the employer

For google, that's pretty much all software related projects.

Re: Software Engineering at Google

#158

Post by richsinn »

jeremyjh wrote: post #69
richsinn wrote: post #23

Earlier quoted context omitted.

> Mostly just stuff any competent company would/should be doing. it's google though, so they act like it's super awesome. Yes, you're absolutely correct. But here's the thing - it was actually Google that pioneered many of this. Many of the big/competent companies that are following these practices are because of Google's "DNA" leaking into those companies (via former employees bringing along the best practices learn…

They may have done a better job instituting these practices across a large organization, and some of their tools have very useful and novel features, but I very much doubt there is a single practice that they actually invented. If you think there is one, please be specific. I think what Google contributed is evidence that these practices can be instituted at scale, which really was sorely lacking in some cases. This…

Of course it's hard to say if they completely, 100% invented anything from scratch. But they sure did "pioneer" a lot of unique practices that other software companies were not following at the time.

A specific example - the practice of keeping the entire codebase at the company under a single "source" repo. Pre-Google - it would've been considered outrageous to have the entire codebase of a sophisticated software company keep their entire software contents under a single repo. But Google did it, and other companies have followed suit successfully (as Google DNA has leaked to other companies).

Yes, of course keeping code in a single repo is not a "new invention". Linux is a single repo; many smaller companies have only a single repo because their only product is a single web app. Google keeps nearly 100% of their entire codebase in a single repo - and that was definitely a novel approach at the time.

Re: Software Engineering at Google

#159

Post by halflings »

dasil003 wrote: post #109
halflings wrote: post #53

Earlier quoted context omitted.

No need to be needlessly sarcastic. Data-driven means that you collect various metrics on dev workflow, what slows productivity, or on the product side (user patterns, retention, etc.) and use those when making decisions. Unfortunately, many companies still base their decisions very simplistic metrics and/or on "instinct".

Sorry, it was late and I didn't want to write a more substantive response. The issue here is that politics are unavoidable. Being more data-driven is just another way of running your political process. And yes, it's a better way as long as you know its limitations. Collecting data and sifting through it to extract useful information takes time, creative thinking, and even "instinct" to figure out the right questions…

Agreed! I also hate it when people think their methods are so rational that they represent the ground truth, and are not biased in any way.

Re: Software Engineering at Google

#160

Post by qu1j0t3 »

gsylvie wrote: post #17
williadc wrote: post #12

Earlier quoted context omitted.

Finance people do.

Good point. I meant software engineers rarely get promoted for saving money.

They sure do at Amazon. Frugality is one of the explicit leadership principles and initiatives often have cost saving as a primary goal and always as a secondary goal.
Post reply on HN