If you’re a manager, there’s a decent chance that the subject of coding standards makes you want to bang your head against a wall repeatedly. If you’re a developer, you can probably understand why this is true of your manager, if you think about it.
The group coding standard has the following properties.
- It’s extremely technical and granular.
- Developers tend to squabble about it.
- If it produces any business value, it does so obliquely and theoretically, from management’s perspective.
Thus, if I’m a manager, there’s this inscrutable document out there that causes my team to argue, and whose existence I must take on faith to be a good thing. As you can see, it doesn’t start out on my good side.
Do Coding Standards Matter?
There are all manner of opinions and arguments to be found on the internet as to why coding standards matter (or don’t). I’ve written about the subject myself from time to time (such as: Bringing Objectivity to Clean Code.). So, without belaboring the point, I’ll make the quick business case for it.
The purpose of a coding standard, at its core, is twofold:
- It promotes maintainability by making all code look similar and familiar to all developers.
- It standardizes approaches that promote correct code (and avoid incorrect code).
Thus, on the whole, the coding standard makes the total cost of ownership of the codebase decrease by some amount ranging between 0 and “indeterminate.” As an outside party, you simply have to take on faith that there is an ROI and that the amount of time wasted in arguments, complaining, and compliance is offset by the reduced troubleshooting and onboarding times.
And, in my experience, it generally is. Notwithstanding pouting and bickering that happens early in the project and makes life unpleasant, it’s better to have these things than not to have them. The key, then, becomes minimizing the cost of having the standard. And you do this by securing compliance with the least amount of heartburn for all involved.
So how do you do that? How do you convince the developers to buy in with a minimum of resistance and friction?
Understand Your Personnel
The first thing you need to do is take stock of your team’s dynamic and understand the impact that a relatively bureaucratic-by-nature institution will have on them. Introducing coding standards to a development team is like introducing an “appropriate decoration policy” to a neighborhood of houses — some team members will be apathetic, some will be enthusiastic about telling everyone how to work, and some will be resentful of any meddling in what they do.
With this in mind, do not, for instance, allow your most meddlesome or irksome team member to have free reign. Instead, understand your team and facilitate an introduction of the concept in a way that will minimize friction. If you have a natural leader admired by all, perhaps that should be the person to introduce it. If you have a team member that will object to any suggestion posed by others, task him with making the suggestions instead. You know the team and its dynamic, so use this to be a facilitation enabler.
Limit the Scope
The next important consideration for buy-in is to limit the coding standards, especially at first, to things that demonstrably solve problems. Resist the impulse to google around until you find a 50-page document on the internet, and then to take that and modify it. Less is more here.
In my experience, the standard should contain items that solve a problem seen in the past. For instance, if the codebase has historically had two disjoint variable naming schemes, then standardization will help. If, however, the team has not struggled with this, then there’s no reason to introduce a rule. You’ll get all of the annoyance from the team with none of the benefits.
Automate, Automate, Automate
The two pieces of advice that I’ve offered up to this point orient a lot around soft skills. Manage personalities and limit opportunities for discord and, hopefully, the team will willingly adopt the standard. And yet, it’s still possible that they won’t.
You might have good faith efforts, but people are forgetful. You might have annoyed, half-hearted efforts only if people do not buy in. And when that happens, the inevitable bickering starts, and you start to want to bang your head against the wall that I mentioned earlier. Arguments ensue. One team member appoints himself “standards cop” and starts hassling the others from a position of self-righteousness. Another team member adopts the passive-aggressive, “too cool to care” position. It can be a mess and a headache.
Unless, of course, you make such things impossible. There’s a great piece of advice that I’ve heard before, and it applies well to people management and new technique adoption both at the same time. Build a system, and, when things go wrong, blame the system.
When it comes to a coding standard, here is what you can do. First, make sure that you’re practicing continuous integration and that you have a build machine. With that in place, take your nascent coding standard and use a static analysis tool to analyze the code and render a “compliant or not” verdict. From there, you can just add this analysis to the build, meaning that non-compliance causes a broken build.
In one fell swoop, you’ve transformed the coding standard from “annoying afterthought requiring nagging” to “just part of making software that works.” There’s no need to send angry emails — developers literally cannot call their work done until it is compliant.
Not only does this ensure that the standard is followed, but it pretty much eliminates any sustained friction among team members. They may be initially annoyed, but after the build integration, their annoyance, if it exists, will be directed at the build. Or, to put it another way, they’ll blame the system instead of each other.
Adoption of a coding standard can be a tricky goal, but with automation via static analysis, it’s really kind of a gimme.
