Software Engineering at Google

Fergus Henderson, who has been a software engineer at Google for 10 years, published the PDF document entitled “Software Engineering at Google“, where he collects and describes key software engineering practices the company is using.

It covers the following:

  • software development – version control, build system, code review, testing, bug tracking, programming languages, debugging and profiling tools, release engineering, launch approval, post-mortems, and frequent rewrites.
  • project management – 20% time, objectives and key results (OKRs), project approval, and corporate reorganizations.
  • people management – roles, facilities, training, transfers, performance appraisal and rewards.

Some of these practices are widely known, some not so much.  There are not a lot of details, but the overall summaries should provide enough food for thought for anyone who works in the software development company or is involved in management.

 

What is ChatOps? A guide to its evolution, adoption & significance

HipChat blog runs a rather lengthy post on what ChatOps are – “What is ChatOps? A guide to its evolution, adoption & significance“, which provides some insight into how the new generation of teams communicate.

At Qobo, we are at Stage 3 – Gimini, with a whole lot of dedicated rooms (one for each project, and a few more), some workflows (most notably “Hey Leonid, can you merge and deploy this pull request please“, or a shorter “@leonid, please m&d”), and some automation (we get monitoring notifications from Nagios and Zabbix, repository activities from GitHub and BitBucket, as well as do project deployments using slash commands).

We haven’t eliminated email completely, but combined with Redmine project management tool, we’ve significantly decreased the role of unstructured emails in our work.

Thoughts on Running an Open Source Project

Thoughts on Running an Open Source Project

I love it when people share their code, just make something and publish it, but to my mind it isn’t an open source project until it has people around it. There’s nothing wrong with building something as a hobby, but it’s quite different to have people around it.

On managing Linux kernel development

The Linux kernel is one of the largest collaborative software projects in the history of the world and has almost nothing in the way of formalized management structure. We have people who have a strong operating systems background who have been contributing code, and then we have people like me. I have a background in fruit fly genetics and yet someone lets me get close to the Linux kernel; this seems wrong. And then we have people who are genuinely kids in their bedroom. It’s a miracle it works as well as it does. We should be astonished that we’re able to get it so right so much of the time.

Matthew Garrett