Engineering practices in big tech
Google
- Eng. Practices Guide (wiki)
- Software Engineering at Google (paper)
- Software development
- development always at “head”
- code ownership
- hermetic build system
- each push must be reviewed by at least one engineer
- small changes encouraged over bigger ones (CLs labeled as S, M, L, XL)
- Buganizer: bug tracking system. Bug triage practices
- insist on using limited number of (5) programming languages: C++, Java, Python, Go, or JavaScript
- advantage:
- reduces obstacles to code reuse and programmer collaboration
- Protocol buffers for interoperating between different programming languages
- single command set for usual tasks no matter which language (e.g. check out, edit, build, commit, file bug, …)
- canary services
- post-mortems
- Frequent software re-writes (each 1-2 years) !!
- benefits exceed the cost
- motivations:
- requirements change significantly in few years in a typical project, software designed around old requirements is most of the time not optimal for current requirements
- software accumulates complexity over years
- benefits:
- increases sense of ownership of new engineers in the project
- encourages mobility of engineers between projects
- ensure code is written in recent tech and methodology
- costs:
- Project management
- each engineer allowed to spend upto 20% time on any project
- Objectives and Key Results (OKRs)
- People management
- tech leadership and people management distinction
- seperate career progression for engineering and management
- Roles:
- Engineering manager
- selects tech leads, responsible for team performance, coaching assistance in career development, performance evaluation, some aspects of compensation and hiring
- manages 3 to 30 people. 8 to 12 is most common
- Software Engineer
- Research scientist
- Site-realibility engineer (SRE)
- Product manager
- Program manager / Technical program manager
- similar to product manager, buut rather than product manages processes (e.g. data collection)
- Facilities
- open plan seatings
- Pros: encourage communation, economical
- Cons: less concentration
- Blog arguing against open offices
- What It Takes to Get Certified to Review Code At Google (news)
- Modern Code Review: A Case Study at Google (paper)
- Why Google Stores Billions of Lines of Code in a Single Repo (talk)
- Trunk-based development
- Advantages of a monolithic repo
- single source of truth
- diamond dependency problem
- easier to modernize codebase
- tooling support
- code review, code search, tricorder, presubmits, testing before and after commit, auto roll-back, change distribution and management
- Warning: this may or may not be the right approach for your company
Microsoft
- Company’s Research department for empricial research on software productivity. Find many research papers at (RISE website)
LinkedIn
- Scaling Collective Code Ownership with Code Reviews (blog) (talk) -> gives links to very useful empirical research papers
- Effective Code Reviews and File Ownerships (blog)
Netflix
- How we build code at Netflix (blog)
Review Papers
- Rigby, Bird. 2013. ACM. Convergent Software Peer Review Practices (Microsoft Research paper)
- “We examine two Google lead projects, Android and Chrome, three Microsoft projects, Bing, Office, and MS SQL, and one project internal to AMD. We contrast our findings with data taken from traditional software inspection conducted on a Lucent project, a compiler, and from open source software peer review on six projects, including Apache, Linux, and KDE”
Empiricial Studies
- Bird, Bacchelli. 2013. IEEE. Expectation, Outcomes, and Challenges of Modern Code Review (Microsoft Research paper)
* “We empirically explore the motivations, challenges, and outcomes of tool-based code reviews. We observed, interviewed, and surveyed developers and managers and manually classified hundreds of review comments across diverse teams at Microsoft”
- Code Reviewing in the Trenches: Understanding
- Challenges, Best Practices and Tool Needs (Microsoft Research paper)
- The Best Kept Secrects of Peer Code Review (Palantir book)
Resource resources
- Software Craftmanship North America Conference (talks)
Insights from classics
- The Mythical Man-Month (https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=sr_1_1?crid=39RLOV4C701C0&keywords=the+mythical+man+month&qid=1572769488&sprefix=the+mythical+man+%2Caps%2C517&sr=8-1)
- adding manpower to a late software project makes it later (known as Brook’s Law)
- “The idea behind microservices is that some types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together.” (blog)