On Enforcing Coding Guidelines
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.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, 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, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe of interest to you, too:
- Next: Understandable-Simple vs. Minimal-Simple Code
- Previous: What Happens When You Email the Companies That Are Responsible for 71% of All Greenhouse Gas Emissions
- More under Web Development and Engineering Management, or from 2017
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.