Code Quality – Organizing awareness with in the team

This article covers the fourth part of the series of articles Code Quality – Learn, Measure and Organize Awareness which is about the Code Quality – Learning code quality aspects, Using different code quality Measurement Tools and How to organize the awareness with in the team. Here we will discuss about how to organize the quality awareness with in the team.

Why to share code quality knowledge/learning?

Consider sharing code quality concepts knowledge something similar to sharing domain, functional or any other technical knowledge with in a project. In every project, you will always find people with different domain and technical knowledge and same goes for the code quality capabilities also. I hope we all agree upon how important knowledge sharing with in the team is and especially for the Agile teams. Even if you fix some code quality related issue in your project but until and unless you share it with others, the same people will be more prone to do the same mistake again. And if you don’t talk about the quality issues, people may loose the motivation and may be next time they will be more relaxed in doing same errors again.

How to share and organize code quality knowledge/learning?

It depends a lot on the team how they decide to go ahead with it and what suits the best to them. Depending on the team try to find out the best way to share this knowledge and organize awareness with in the team.

Some of the ways you can try and adopt are:

Pair Programming: The best way to do the instant code review and take design decision and quality discussion during the development time is by doing the pair programming. Two minds working on the same piece of code and giving feedback on the nature of the code at that moment itself help to solve the problem there only rather than post poning it for later code review.
Wiki: Some teams prefer to use wiki to store this information. Depending on the situations like distributed teams, new people joining the team very frequently etc. make more sense here to use some kind of wiki to keep this information so that it is available to everyone and all the times and can be referred later also. But sometimes it is hard to maintain these documents and these become irrelevant over a period of time, decision is on the team.
Coding Standards Document: I still remember that during initial programming days in waterfall project, we used to have such document so that everyone in the team follow the same coding practices which were used during code review for check list. Well, in Agile it is hard to follow such documents and it is irrelevant but still if it works for you then it is fine.
Mailing List:Some teams create separate mailing list to share the learning so that everyone receives it and the whole team is on the same page.Going through a mail is easier than going through a long document.
Fixing the issue and letting people know: When you find the quality issue, try to fix it and let the relevant person know about the changes so that they don’t make the same mistake again. In Agile teams, collective code ownership is the good example and try to make it work for you.

Depending on the teams, whether collocated or distributed, do whatever works for you. The collocated teams prefer to talk to the person directly because it reduces the communication time etc. which is difficult in case of distributed teams. In case of the distributed teams it is a bit harder to share this knowledge and many more questions rise like Is the cheap developers really cheap and as a team you try to solve these issues.

Few points that you should take care of and I would like to mention are:

On-going process: This is an on going process, prepare team to follow it continuously.
Share in positive way: Don’t shout on that who made the blunder with out fixing it. Fix it and share the learning in a positive way.
Motivate people to fix it and share: Motivate people to approach the bad code and make changes to it and encourage it.
Talk more about quality: Talk more about it with the team and the ways to improve it.
pair-up more: Put people with different technical expertise together more often.

All the teams work in different ways and it is hard to mention single thing which we can guarantee that will work best for all the team. In the end it is up to the team how it approaches the problem and what works for them. Talk to the team what should you do to over come the quality related issues and adopt over time.