Software Engineering at Google

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

est31Jul 25, 2022View on HNParent context

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).

chrchang523Jun 9, 2022View on HNParent context

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

fergus_googleOct 11, 2020View on HNParent context

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…

RecursingJun 7, 2020View on HNParent context

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

est31Mar 17, 2020View on HNParent context

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…

dclusinSep 24, 2019View on HNParent context

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

kronaSep 6, 2019View on HNParent context

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

LawnboyMaxMay 30, 2019View on HNParent context

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…

est31Mar 14, 2019View on HNParent context

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

ddulayJan 3, 2019View on HNParent context

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

iandanforthFeb 13, 2018View on HNParent context

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.

mm321May 25, 2017View on HNParent context

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

adjkantApr 7, 2017View on HNParent context

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

sulsMar 14, 2017View on HNParent context

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…

NumberSixFeb 19, 2017View on HNParent context