Culture as Code

/via http://geek-and-poke.com/

Think about the way you “do code” at work”. You probably have a process, right? Something like “grab a ticket from JIRA, create a branch, write code, squash commits, …”, right?
Now, think about the way others on your team code. Broadly speaking, they probably all follow the same system, except when they don’t. And now that you’re really thinking about it, you’ve probably got a couple of peeves around how, well, pretty much everybody else is (not) following process. I mean
• Alice is great, except she sometimes forgets to squash commits
• Bob is great too, except you have to keep reminding him to lint his code
• Carol, wow, she’s stellar! Except…she never bumps the version number on checkin
and so on.

The thing is, pretty much all of them probably have exactly the same opinions about each other, and you! I mean, while you may think it’s ok to not comment your code in the really obvious cases, maybe Alice/Bob/Carol/… think otherwise?
This, boys and girls, this superset of “process that isn’t followed” is what your tech-lead/PM/engineering mgr/whatever deals with all the time, every day. After all, it may be just the one thing that you slip up on, but think of this across all the developers, and then across all the teams, well, it’s pretty hair-raising.

Whats worse is that this doesn’t just scale linearly — there are all sorts of emergent behaviors that come into play that compound the situation. For example
 — David forgot to reference the JIRA ticket reflecting the changes he made. As a result, the ticket didn’t get closed, and the UI team was un-necessarily blocked for an entire week
 — Elaine’s missing unit-test wasn’t caught in code-review. The resulting edge-case bug got triggered in production, and the ops-team almost #RageQuit.
etc.

The point here isn’t that “bad things” won’t happen — as sure as little apples, they will. It’s more that avoidable “bad things” need to be minimized, in particular the ones that are self-inflicted.

This isn’t a particularly new realization. Atul Gawande has a great book called “The Checklist Manifesto” that goes into detail on this, on how a simple checklist, when followed consistently, can dramatically reduce error-rates.
The trick, however, is in ensuring that everybody actually follows the process.

Which brings us back full circle to software development, and process. There is only so much that you can make people do, eventually they start rebelling, checking out, or just plain get disinterested. However, what you can do is embed the process into the workflow, so that the golden-path automagically ensures that the process gets followed.

There is any amount of obvious stuff here, things like using JIRA workflows alongside Kanban, setting up GitHub to insist on Code Reviews before branches can be merged (•), and, well, so many things that your PM or ProdMgr does.
There are also “advanced” tools/techniques that you can use, like Danger, which allows you to introspect your PRs before review (it’ll do things like reject the PR if you didn’t add a ChangeLog, run the unit-tests and kvetch when it finds DEBUG messages, etc.)

The bottom line though is that you should try and get to a place of “Culture as Code” (••). The more your process is embedded into your culture, and expressed as parts of the system itself, the more likely it is that everybody will follow it. After all, not following it actually involves mucking with the system, turning off flags, and such-like, and who has the time for that!
For a practical implementation thereof, check out this article by Ajey Gore on Checklists at GO-JEK.

(•) GitHub has a ton of flags that you can mess with — learn them! They are useful!
(••) Yes, “Culture as Code” in the same vein of “Infrastructure as Code”