How to ensure adherence to coding standards

Question

We have a coding standards document that contains standards for SQL.

In the last sprint, there were some standards that were missed by the Developer, and also missed by the Reviewer.

We just had a meeting where some folks thought adding a checklist document to every ticket tagged with "SQL" would give the Reviewer a bar to measure with. Some suggested adding custom fields/checkboxes to Jira (web) tickets.

Neither solution is ideal in my estimation. On previous teams, the coding standards were like an ethos that was upheld by the Application Development Manager, believed in by the team, and taught to new Devs when onboarded. The only thing tolerated was hitting the standard.

The SQL standards are somewhat new, since we just hired on a new DBA. I'm trying to understand if this is an education task, a process task, something else, or a combination.

Answer 1

In order to be cared about, standards must be understood.

You say that

a checklist[...]/checkboxes [are not] ideal

because

On previous teams, the coding standards were like an ethos that was upheld by the Application Development Manager, believed in by the team, and taught to new Devs when onboarded.

What I take from this is that your primary concern is that you want the team to care about the standards, not just agree to and uphold them for the sake of agreeing and upholding. (Correct me if I'm wrong.)

In order to do that, your team must understand the standards, and why they exist.

Consider the following three conversations.

1. "Look both ways before crossing the street." "Why?" "I don't know, it's just what I've been told."
2. "Look both ways before crossing the street." "Why?" "Because it's the law."
3. "Look both ways before crossing the street." "Why?" "Because if you don't, it's more likely you will get hit by a car, which will result in either a bloody death, or maybe severe injuries, such as a spinal injury that will make you unable to ever walk again."

Now consider the following three conversations:

1. "Never concatenate strings to SQL." "Why?" "I don't know, it's just what I've been told by the DBA."
2. "Never concatenate strings to SQL." "Why?" "Because it's on the checklist."
3. "Never concatenate strings to SQL." "Why?" "Because if you concatenate a string containing user input to your SQL instead of properly parameterizing it, you open yourself up to an SQL injection attack, which can give hackers way more access to our database than we want to give them."
   • (Followed, of course, by "Doesn't that mean it's okay to concatenate constant strings to SQL?" "You're right. Let's update the standard.")

Do you see the similarities and differences there?

Answer 2

In my experience the most effective coding standards are those that are driven directly by the developers.

An approach I have seen work well is to have a developer community of practice that discusses coding standards and agrees them by consensus.

By introducing standards in this way the developers have a buy-in to them being successful. If they feel a coding standard is not of value they can raise this in the community and have it discussed. If the consensus is that the standard does not add value then it can be dropped.

Answer 3

In this case, the easiest solution would be to use some linters for the code you produce, be it SQL or something else. See also:

• Lint (software)
• List of tools for static code analysis

These tools will automate some of the rules, but they only cover syntax. You still need people to agree together on a standard of quality and then stick to it because it's something important for them. This isn't as easy to obtain as syntax checking with tools though.

You should bring this topic up in your next retrospective, figure out what happened, and together agree on what you could do next. Try to keep things simple though.

Revisit the topic if things happen again and remind everyone that it was a decision they took together and agreed to implement because it was important. If things keep on happening then that may be a sign they only agreed with the coding standards in words and they don't actually back that with their actions.

No amount of tools, standards or processes will guarantee the standards are followed if people don't consider the adherence to the coding standards to be valuable and the normal way of working.

Answer 4

As you wrote, it's likely a combination of education and process task.
The coding standard needs to be understood, digested and practiced before it becomes a habit and part of the professional ethos.

I find that Definitions of Done are very useful to educate the teams and get these habits embedded in the normal way of working.

You could add a dedicated checklist in the DoD and - as time goes by and teams improve - it can be removed or made more sophisticated.
If you use also Confluence, it's very easy to link a Confluence page containing the checklist associated to a DoD, to a Jira item. You can also make that the Jira story can be transitioned only if the checklist has been filled.

Answer 5

In the last sprint, there were some standards that were missed by the Developer, and also missed by the Reviewer.

Why it was missed? Was it due to lack of time or lack of intention?

If it is due to lack of time, then when you plan next sprint, the development team should keep aside estimates to make sure they check that the code they develop is adhering to the coding standard. You can try pair programming being applied here where another developer can ensure coding standards are in place when first developer finishes his development work.

If it is due to lack of intentions by the development team, then as mentioned in other answer posts, do an honest and candid discussion during retrospective about the real need of adhering to the coding standard.

If development team is in complete agreement that coding standards needs to be followed then 1 more option could be to include adhering to coding standard as part of the acceptance criteria of the user story. That way, the development team will know that the user story cannot be marked as "done" unless they adhere and implement the code as per agreed coding standard.

Answer 6

Here's what I would do next: "take your concerns back to them." Alert them to the fact that you perceive that the standards are not being "properly" adhered to, and "ask them why." Listen very carefully to what they say.

The technical issues and concerns, particularly with SQL, have already been brought forward in this thread and are valid. But, the team itself should also fully know them. "Raise the concern that 'you are concerned,'" then listen to what happens next, and use this to inform your next move. If you like, raise your findings again with this community for further feedback. (The objective being, not to weigh their response on its technical "merits," but to further consider how to manage it.)

Answer 7

Project management normally includes a quality management plan; having coding standards is one of the steps, but you've got to plan a way to do quality review and acceptance.

Some teams break out the quality acceptance function into a separate team.

Scrum teams (as I understand them) accept the responsibility for delivery an acceptable quality product as part of their self-organizing.

Of course the other answers point out an unstated assumption - quality has to be connected to something. Quality management is about avoiding rework - most devs want to avoid rework. The other answers are excellent at explaining how to contextualize quality.

If the fundamental problem is that the devs don't care, then this isn't a quality problem, this is a case of devs who don't care - and you can't solve that no matter how much you invest in quality.