On Enforcing Coding Guidelines

Published on October 2, 2017 (↻ October 3, 2023), filed under and (RSS feed for all categories).

Surprisingly a snippet from The Little Book of Website Quality Control (updated), not the one of HTML/CSS coding guidelines, a few thoughts on enforcing coding standards.

The cover of “The Little Book of Website Quality Control.”

In the context of coding guidelines, we’ve learned to differentiate between descriptive or positive guidelines and those that are prescriptive or normative […]. The difference is mostly practical—when code quality is at a high level, we merely document (describe) what everyone’s already doing; when code quality is low, we tell everyone what to do (prescribe). However, as it pertains to much of what we’ve discussed so far, this requires some way of enforcement.

How do we enforce quality? This is still a difficult question; so difficult, in fact, that in practice we often see it dodged. Why? Because enforcement easily upsets people, and we don’t want to upset people, not even […] when they report to us. But we’re on the right track here.

Enforcement happens top-down. Executives and managers are to be looked at to emphasize and live quality, to reward good quality, and to—in one way or another—discourage poor quality. How? By doing what we surprisingly forget frequently: measuring quality and tying related metrics to performance evaluations.

Two anecdotes illustrate that approach. There’s one tale of a manager who has, despite efforts of his team to up the ante and increase quality in his department, never endorsed, let alone supported or encouraged those team members’ efforts in team communications or goals. That quality initiative’s efforts, witnessed at one point at a major corporation, suffered a significant blowback.

At the same firm at another time, managers called out the importance of quality and used available data points, like performance scores as measured by Google’s PageSpeed tools, accessibility problems as measured by Sidar’s HERA, or the number of validation errors as measured by W3C’s Link Checker. Although the team in question never got to tie metrics like these to performance evaluations, that precise step was on the table as to [mean] strong encouragement and—ultimately enforce—higher quality.

It’s not my best book, and the overview of tools is not aging well (better consult UITest.com), but I maintain the idea that there still are a few useful things to be picked up.

Was this useful or interesting? Share (toot) this post, or support my work by buying one of my books (they’re affordable, and many receive updates). Thanks!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.

If you want to do me a favor, interpret charitably (I speak three languages, and they can collide), yet be critical and give feedback for me to learn and improve. Thank you!