There are many aspects of good coding practices that don't fall under the normal
areas of testing and tooling that most Engineering Productivity groups focus on
in the software industry. For example, having readable and maintainable code is
about more than just writing good tests or having the right tools—it's about
having code that can be easily understood and modified in the first place. But
how do you make sure that engineers follow these practices while still allowing
them the independence that they need to make sound engineering decisions?

Many years ago, a group of Googlers came together to work on this problem, and
they called themselves the "Code Health" group. Why "Code Health"? Well, many of
the other terms used for this in the industry—engineering productivity, best
practices, coding standards, code quality—have connotations that could lead
somebody to think we were working on something other than what we wanted to
focus on. What we cared about was the processes and practices of software
engineering in full—any aspect of how software was written that could
influence the readability, maintainability, stability, or simplicity of code. We
liked the analogy of having "healthy" code as covering all of these areas.

This is a field that many authors, theorists, and conference speakers touch on,
but not an area that usually has dedicated resources within engineering
organizations. Instead, in most software companies, these efforts are pushed by
a few dedicated engineers in their extra time or led by the senior tech leads.
However, every software engineer is actually involved in code health in some
way. After all, we all write software, and most of us care deeply about doing it
the "right way." So why not start a group that helps engineers with that "right
way" of doing things?

This isn't to say that we are prescriptive about engineering practices at
Google. We still let engineers make the decisions that are most sensible for
their projects. What the Code Health group does is work on efforts that
universally improve the lives of engineers and their ability to write
products with shorter iteration time, decreased development effort, greater
stability, and improved performance. Everybody appreciates their code getting
easier to understand, their libraries getting simpler, etc. because we all know
those things let us move faster and make better products.

But how do we accomplish all of this? Well, at Google, Code Health efforts come
in many forms.

There is a Google-wide Code Health Group composed of 20%
contributors who work to make engineering at Google better for everyone. The
members of this group maintain internal documents on best practices and act as a
sounding board for teams and individuals who wonder how best to improve
practices in their area. Once in a while, for critical projects, members of the
group get directly involved in refactoring code, improving libraries, or making
changes to tools that promote code health.

For example, this central group maintains Google's code review guidelines,
writes internal publications about best practices, organizes tech talks on
productivity improvements, and generally fosters a culture of great software
engineering at Google.

Some of the senior members of the Code Health group also advise engineering
executives and internal leadership groups on how to improve engineering
practices in their areas. It's not always clear how to implement effective code
health practices in an area—some people have more experience than others making
this happen broadly in teams, and so we offer our consulting and experience to
help make simple code and great developer experiences a reality.

In addition to the central group, many products and teams at Google have their
own Code Health group. These groups tend to work more closely on actual coding
projects, such as addressing technical debt through refactoring, making tools
that detect and prevent bad coding practices, creating automated code formatters, or making
systems for automatically deleting unused code. Usually these groups coordinate
and meet with the central Code Health group to make sure that we aren't
duplicating efforts across the company and so that great new tools and systems
can be shared with the rest of Google.

Throughout the years, Google's Code Health teams have had a major impact on the
ability of engineers to develop great products quickly at Google. But code
complexity isn't an issue that only affects Google—it affects everybody who
writes software, from one person writing software on their own time to the
largest engineering teams in the world. So in order to help out everybody, we're
planning to release articles in the coming weeks and months that detail specific
practices that we encourage internally—practices that can be applied everywhere
to help your company, your codebase, your team, and you. Stay tuned here on the
Google Testing Blog for more Code Health articles coming soon!

3 comments
:

You started off by saying that in most organizations there's a dedicated team of engineers (usually tech leads or seniors) who use their free time or a committee to oversee initiatives and guidelines to propagate best practices. From the way the article is written it sounds like you're saying you do something else, but you're example of having 20%ers doing this seems the same as "free time" to me. I know we have Communities of Practice, where everyone interested in these type of strategies and idea sharing can contribute to this. Are you saying Google does something different or just sharing examples of your specific implementation of the industry norm?

First, let me clarify what I meant about my (personal) experience regarding other organizations. I think it's rare for there to be anybody actually dedicated to this. In my experience, at most companies, it's some random good citizen who pushes this sort of thing, not as an official part of their job, and sometimes not even as a senior engineer. Sometimes they get some support from a few other people. It's almost never an organized function that is supported by the company. Sometimes the champion even leaves or gets too busy, and then the whole thing kind of just gets dropped.

When it _is_ a supported function, the focus frequently ends up being on testing and tooling or on a specific language, rather than on what we primarily focus on in code health around refactoring, simplicity, practices, etc. I'm not saying that this is true everywhere, but this is my experience with many organizations.

In contrast, at Google, Code Health is an official group that is recognized by the company. The people who work on it can be recognized and rewarded for their contributions. We have a significant influence, when we want to use it. There are people who work full time on code health, as well.

I think that, as I'm able to publish more specifics of what the various parts of Code Health do, some how of we are different might become clearer. However, if you have any specific questions about what Code Health is and how it functions, please let me know! :-)

Thanks for the reply Max, I can definitely relate to the point you made about champions taking it on themselves and sometimes letting it drop when they leave or get too busy. We have communities of practice, which are really interested parties but are also recognized and encouraged within our company, that determine for the company what our standards are and consider it part of our culture that we stay attentive to this. So I guess we're saying the same thing. We prefer to have the groups more focused than general and communicate with each other. We also read your blog, so I'm sure that as a group we'll have some great discussion around what you guys are doing and what we can do better. Thanks for sharing.