Practices for communicating and upholding code standards

When you create coding and software design standards as a team, your job is only just beginning.

Now starts the never-ending job of communicating and upholding those standards.

I was originally going to write about these aspects separately, but they’re really two sides of the same coin. Good communication and education helps conformance, and concrete conformance practices like automated linting can be educational.

Some practices are more geared at education (e.g. presentational training) and others are heavily focused on conformance at the point of need (static analysis). But there are other practices that can mix the two (code reviews, documentation).

To illustrate this, I’ve created my own 2x2 quadrant chart! I’ve always wanted to make one.

Some practices are naturally aimed at educating or informing developers about standards and guidelines before they start developing implementations, whereas others are more focused on reacting to conformance issues as the get closer to (or are already in) production. There’s a diagonal line from bottom-left to top-right where most approaches site that reflects this.

But there are also other approaches that don’t fit, such as in-person feedback, retrospective code review (not shown) and regular reviewing of the standards themselves.

I’ll go into some of these approaches more next time, but for now:

Does this provide a useful way of thinking about code standards education and conformance approaches? Or have I just made a 2x2 quadrant for fun? Hit reply and tell me what you think!

All the best,

– Jim