Software Engineering at Google · HackerPapers discussions

Software Engineering at Google — mentioned by est31

Mon, 25 Jul 2022 14:42:16 GMT

Google rewrites a lot of their software components from scratch every few years, at least according to section 2.11 of this paper: https://arxiv.org/pdf/1702.01715.pdf

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by chrchang523

Thu, 09 Jun 2022 16:24:55 GMT

Note that Google's "Frequent rewrites" practice -- see section 2.11 of https://arxiv.org/pdf/1702.01715.pdf -- substantially reduces the severity of this problem (though it requires a good higher-level architecture).

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — HN submission

Thu, 06 May 2021 19:46:55 GMT

Software Engineering at Google [pdf]

6 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Software Engineering at Google — HN submission

Mon, 09 Nov 2020 15:39:06 GMT

Software Engineering at Google

4 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Software Engineering at Google — mentioned by fergus_google

Sun, 11 Oct 2020 21:47:43 GMT

For a brief overview of how software engineering is done at Google, see my paper "Software Engineering at Google" <https://arxiv.org/abs/1702.01715>, and with regards to architecture, see in particular sections 2.9, 2 11, 3.3, 3.4, and 4.1. We typically talk more about "design" than "architecture", so for example our architecture is typically documented in "Design Docs".

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by Recursing

Sun, 07 Jun 2020 22:52:40 GMT

I think a lot of it comes from opinion pieces such as this one https://www.joelonsoftware.com/2000/04/06/things-you-should-... which makes incredibly confident and general statements from a very small sample size, while there are many success stories of successful complete rewrites Also, "Most software at Google gets rewritten every few years." https://arxiv.org/pdf/1702.01715.pdf

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by est31

Tue, 17 Mar 2020 21:17:01 GMT

Note that this is a book, it's not, as you'd initially assume, the paper of the same title. https://arxiv.org/abs/1702.01715

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by dclusin

Tue, 24 Sep 2019 17:44:35 GMT

https://arxiv.org/pdf/1702.01715.pdf From the bottom of page 11: Most software at Google gets rewritten every few years... (continues with another paragraph). In most of the companies Ive worked at for more than a few years some major piece of the architecture changes in ways unforeseen by the original designers. This usually incurs massive changes on the frontend, since it's often the glue that wires everything together. Migrating to react from a simpler framework is a minuscule amount of the effort. Large structural changes for growing software products are the norm, not the exception. If…

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by krona

Fri, 06 Sep 2019 11:12:14 GMT

This only works at Google because most of the code is rewritten every few years [1]. The dynamics between tech debt and over-engineering in such a setting are not really representative of the rest of the industry. 1: https://arxiv.org/pdf/1702.01715.pdf

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by LawnboyMax

Thu, 30 May 2019 04:49:39 GMT

Really good overview: https://arxiv.org/abs/1702.01715

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by est31

Thu, 14 Mar 2019 07:25:05 GMT

Google has a giant monolithic code repo with over 2 billion lines of code. It's really amazing. > Most of Google’s code is stored in a single unified source-code repository, and is accessible to all software engineers at Google . There are some notable exceptions, particularly the two large open-source projects Chrome and Android, which use separate open-source repositories, and some high-value or security-critical pieces of code for which read access is locked down more tightly. But most Google projects share the same repository. As of January 2015, this 86 terabyte repository contained a…

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — HN submission

Thu, 03 Jan 2019 19:33:58 GMT

Software Engineering at Google (2017)

685 points; 309 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Software Engineering at Google — mentioned by ddulay

Thu, 03 Jan 2019 10:25:09 GMT

Link to the paper "Why Google Stores Billions of Lines of Code in a Single Repository" https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... Also, "Software Engineering at Google" https://arxiv.org/pdf/1702.01715.pdf

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by iandanforth

Tue, 13 Feb 2018 01:30:16 GMT

I didn't notice a link to "Software Engineering at Google" which is a great article that goes into the monorepo argument as well as a lot of other cool practices. https://arxiv.org/abs/1702.01715

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by mm321

Thu, 25 May 2017 03:43:55 GMT

also they do all the development in one branch / in the trunk https://arxiv.org/abs/1702.01715 ( I never understood the explanations as to why they do that ) Now the article says that with windows they do branches.

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by adjkant

Fri, 07 Apr 2017 01:36:01 GMT

That's related to the engineering practices at Google (3.1 below) > "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" https://arxiv.org/pdf/1702.01715.pdf

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by suls

Tue, 14 Mar 2017 12:43:43 GMT

This. Also, I think that the build system itself is just the tip of the iceberg. At least in Google's case it has recently been very nicely documented [1] that blaze is "just" one piece of how google keeps velocity high [1] https://arxiv.org/abs/1702.01715

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — mentioned by NumberSix

Sun, 19 Feb 2017 18:05:46 GMT

A number of points in the post/article are questionable. First, it assumes the developers had substantial control over the schedule for the project ("Giving excessive importance to estimates"). Certainly in my experience this is unusual. More frequently, the schedule is dictated by management, frequently by sales/marketing executives in commercial software development. It is very difficult to push back and a good way to lose your job. Sales: We have closed this great deal with BigCorp. Can you do X (complicated, challenging software project) by the end of the quarter? Developers: Err, um, X…

Paper and discussion history. A mention is not an endorsement.

Software Engineering at Google — HN submission

Fri, 10 Feb 2017 22:15:22 GMT

Software Engineering at Google

442 points; 156 discussion replies on HN. Paper and source history. A submission is not an endorsement.